Gitプルにより、コミットログに無関係な「マージブランチ」メッセージが表示される

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

これが起こっていることです

1. 私たちの1人（彼を開発者Aと呼びましょう。ただし、どちらを使うかは問題ではありません）が一連のコミットをGitHubにプッシュします。
2. もう1人（開発者B）は、ローカルコミットをいくつか行います。
3. Bは git pull。
4. Bは git push。
5. コミット履歴ログを見ると、github.com：foo / barのMergeブランチ「master」が表示されます

コミットログには、「マージブランチ」メッセージが散らばっていて、開発者Bが開発者Aが行った変更をコミットしていることもわかります。この問題を防ぐ唯一の方法はgit pull --rebase、手順3でaを実行することでしたが、リベースによってどのような副作用が発生するのかわかりません。これは、マルチ開発者のgitリポジトリで作業するのが初めてなので、これは通常の動作ですか？この問題を解決する方法についての考えはありますか？

あなたが見ているコミットは完全に問題ありません。がpull効果的に実行されるgit fetchと、git merge通常、実行時にマージが発生しますgit pull。

マージの代わりにリベースを使用する代わりの方法も可能ですが、通常はそれを避けるべきです。リベースを使用すると、線形履歴を保持できますが、最初に発生した分岐に関する情報も削除されます。また、現在のブランチの履歴が書き換えられ、ターゲットブランチ（この場合はリモート）に含まれていないすべてのコミットが再作成されます。再作成されたコミットは異なるコミットであるため、他のユーザーと一緒に開発する場合、特に人々がそれらのコミットの一部をチェックアウトしてから書き直される前に（たとえば、機能ブランチを使用する場合）、多くの混乱を引き起こす可能性があります。経験則として、あなたは決してすべきではありませんすでにプッシュされたコミット書き換えないで。

表示されるコミットは、2つ（またはそれ以上）のブランチを組み合わせるためのものです。複数のブランチをマージしてから他に何もしないコミットを行うのはまったく問題ありません。実際、履歴を見たときにブランチを結合するマージコミットがあると、それは非常に明確になります。リベースと比較して、マージはまたオリジナルを効果的に見ることを可能にします、共存した実際のブランチを含め、開発され履歴。

つまり、簡単に言えば、そうです。マージコミットは完全に問題なく、心配する必要はありません。

私の理解、図、結論が正しくなかったため、この回答は修正されました。

git pullgitがマージしているため、マージコミットが発生します。これは、マージの代わりにリベースを使用するようにブランチを設定することで変更できます。プルでマージの代わりにリベースを使用すると、共有リポジトリにより線形の履歴が提供されます。一方、マージコミットはブランチでの並行開発努力を示しています。

たとえば、2人が同じブランチで作業しています。ブランチは次のように始まります：

...->C1

最初の人が作業を完了してブランチにプッシュします。

...->C1->C2

2人目は作業を終えてプッシュしたいが、更新する必要があるためにプッシュできません。2人目のローカルリポジトリは次のようになります。

...->C1->C3

プルがマージに設定されている場合、2人称リポジトリは次のようになります。

...->C1->C3->M1
      \      /
       ->C2->

ここで、M1はマージコミットです。この新しいブランチ履歴はレポにプッシュされます。代わりに、ローカルリポジトリをリベースするようにプルが設定されている場合は、次のようになります。

...->C1->C2->C3

マージコミットはありません。歴史はより直線的になりました。

どちらの選択もブランチの履歴を反映しています。gitでは、希望する履歴を選択できます。

実際、リベースがリモートブランチに問題を引き起こす可能性のある場所があります。これはそれらのケースの1つではありません。リベースを使用することをお勧めします。これは、すでに複雑なブランチ履歴を簡素化するだけでなく、共有リポジトリに関連する履歴のバージョンを表示するためです。

Branch.autosetuprebase = alwaysを設定して、gitがリモートブランチをマスターではなくリベースとして自動的に確立するようにできます。

git config --global branch.autosetuprebase always

この設定により、gitは各リモートブランチの構成設定を自動的に作成します。

branch.<branchname>.rebase=true

これは、すでにセットアップされているリモートブランチに対して自分で設定できます。

git config branch.<branchname>.rebase true

@LaurensHolstに以前の発言を質問し、追求してくれたことに感謝します。私は確かにgitがプルコミットとマージコミットでどのように機能するかについてさらに学習しました。

マージコミットの詳細については、ProGit-Bookのプロジェクトへの貢献を参照してください。専用の小さなチームのセクションのショーは、コミットをマージします。

できるよ：

git pull --rebase

ただし、これにより常に変更内容が共同編集者の上に置かれます。しかし、汚染メッセージは表示されません。

これには実際にはもっと簡単な答えがあります。開発者Bに、コミットする前にプルを実行させるだけです。これは、リモートリポジトリのコミットの履歴とマージしようとするローカルコミットからローカルリポジトリに作成した履歴が原因で発生するため、これらのマージコミットを防止します。プルを実行したときに「変更は上書きされます」というメッセージが表示された場合は、両方が同じファイルに触れたことを意味するだけなので、次のようにします。

git stash
git pull
git stash pop

その後、マージの競合があれば解決できます。

git pullを実行すると、「マージブランチ」メッセージが挿入されます。これはまさにそれが行うことです。git pullを実行すると、リモートブランチがローカルブランチにマージされます。

git pullを実行して競合がある場合、gitログには、競合を解決したユーザーからの競合ファイルの更新が表示されます。これは、競合を修正した人がファイルを再コミットしたためだと思います。

私の知る限り、これはgitのしくみであり、回避策はありません。

リベースするとgitの履歴が消えるので、マージがいつ発生したかはわかりません。