[解決済み] Gitのプルにより、コミットログに余計な "Merge branch "メッセージが表示される。

質問

私はあるプロジェクトで他の開発者と働いており、リモート リポジトリとして Github を使用しています。私は Mac で git 1.7.7.3 を使用しており、彼は Windows で git 1.7.6 を使用しています。

これが起きていることです。

1. 私たちのうちの一人 (開発者 A とします。どちらでもかまいません) が GitHub に一連のコミットをプッシュします。
2. もう一人 (開発者 B) はローカルでコミットします。
3. B は git pull .
4. Bは git push .
5. コミット履歴のログを見ると github.com:foo/bar のブランチ 'master' をマージします。

コミットログは時間とともに "Merge branch" のメッセージで散乱し、開発者 B が開発者 A が行った変更をコミットしたように表示されるようになります。この問題を防止するために私たちが見つけた唯一の方法は git pull --rebase を実行することです。しかし、リベースによってどのような副作用が発生するかはわかりません。複数の開発者がいる git リポジトリで作業するのは初めてなので、これは通常の動作なのでしょうか？この問題を解決する方法について何か考えがありますか？

どのように解決するのですか？

表示されているコミットは全く問題ありません。A pull は事実上 git fetch を実行し、次に git merge を実行すると、通常、マージが行われます。 git pull .

マージの代わりにリベースを使うという選択肢もありますが、通常は避けるべきでしょう。リベースは直線的な歴史を保つことができますが、元々起こったブランチに関する情報をすべて削除してしまいます。また、現在のブランチの履歴が書き換えられ、ターゲットブランチ (あなたの場合はリモート) に含まれていないすべてのコミットが再作成されます。再作成されたコミットは 異なる 特に、書き換えられる前にそのコミットの一部をチェックアウトしている人がいる場合 (たとえば feature ブランチなど)、他の人と一緒に開発するときに大きな混乱が生じる可能性があります。そこで、経験則として は決して を実行する必要があります。

あなたが見たコミットは、2つ（あるいはそれ以上）のブランチを結合するためにあるものです。複数のブランチをマージする以外のことをしないコミットがあっても、まったく問題ありません。実際、履歴を見ると、ブランチを結合するマージコミットがあることが一目瞭然です。リベースと比較すると、マージは効率的に オリジナル の履歴を見ることができます。

つまり、長い話を短くすると、マージコミットがあることはまったく問題なく、心配する必要はありません。