同僚と私は、単一のリモートオリジンリポジトリでgitを使用しています。私たちは両方ともローカルをコミットしてから、オリジンにプッシュします。私たちが働いているので、当然、いくらかの相違があります。
オリジンにプッシュするときが来たら、ローカルをマージしてからオリジンにプッシュできると思います。説明されたマージなしで、かなりまっすぐなバージョン履歴を取得することを期待していました。
かなり複雑なバージョンのSubwayMapと、繰り返し発生するMergeブランチの「master」メッセージから判断すると、私たちは正しくないことをしていると思います。
以前ここで答えられたような気がしますが、集めた情報がよくわかりませんでした。
同様のケースがあります。中央のマスターリポジトリを使用していますが、多くの場合、個々の開発者がマージブランチの「マスター」メッセージを生成しています。git pull --rebase私たちの解決策は、リモートマスターリポジトリからプルするたびに開発者に実行させることでした。
私はあなたが探していると思いますgit rebase。
履歴に記録された各マージは、「真の履歴を保持する」という観点から必要でした。この時点でブランチが分岐し、その後マージされました（両方のブランチに固有のコミットがあるため、早送りはできません。
リベースすると、現在のヒント（同僚からの変更を含む）が新しい分岐点になり、それらが間に合わない限り、変更を早送りで適用して、線形開発の印象を与えることができます（ただし、 -単調なタイムスタンプ）。
あなたはすべてを正しくやっています。あなたは同時に開発し、時々あなたの仲間の変化を統合し、そしてgitこの歴史を正確に記録します。
リベースによってマージコミットを「回避」することはできますが、一般的にはマージ履歴を維持することをお勧めします。コミットをリベースするときはいつでも、新しいコミットを効果的に作成します。そして、それらの嘘は通常良性ですが、後で問題を引き起こす可能性があります。これは、リベースされたコミットごとにテストスーツの再実行をスキップする場合に特に当てはまります。
「直線的な歴史を作る」という考え全体は、少し見当違いの清潔さだと思います。あなたは本当に線形の歴史を望んでいません。真の履歴が必要です。これは、すべてのコミットが実際にテストされた履歴です。git bisectこれにより、後で意味のある結果で実行できるようになります。
TL; DR：習慣を変えないでください。そのままでいいです。そして、あなたは将来彼らに感謝するかもしれません。