在提交日志中，Git pull导致无关的“合并分支”消息
我正在与一个项目的另一个开发人员合作，我们使用Github作为远程回购。 我在Mac上使用git 1.7.7.3，他在Windows上使用git 1.7.6。
这是发生了什么事
- 我们中的一个人（让我们称他为开发人员A，但哪一个并不重要）将一组提交推送给GitHub。
- 另一个（开发者B）进行一些本地提交。
- B做一个
git pull。 - B做
git push。 - 查看提交历史日志，我看到github.com:foo/bar的合并分支“主”
随着时间的推移，提交日志充斥着“合并分支”消息，并且还显示开发者B提交了开发者A所作的改变。 我们唯一能够避免这个问题的方法git pull --rebase在第3步做一个git pull --rebase ，但是我不知道rebasing会带来什么样的副作用。 这是我第一次在一个多开发人员的git repo上工作，那么这只是正常的行为？ 任何想法如何解决这个问题？
你看到的提交是完全正确的。 pull有效地运行git fetch ，然后git merge所以当你运行git pull时，通常会发生合并。
可以使用重新绑定而不是合并的替代方法，但通常情况下应该避免使用。 重新激活允许您保留线性历史logging，但也会删除有关最初发生的分支的任何信息。 它也会导致当前分支的历史被重写，重新创build目标分支中没有包含的所有提交（在你的情况下，远程）。 由于重新创build的提交是不同的提交，因此在与其他人共同开发时可能会引起很多混淆，特别是当人们在重写之前（例如使用function分支）已经提交了部分提交。 所以作为一个经验法则，你不应该重写任何已经被推送的提交。
你看到的提交在那里结合两个（或更多）分支。 有一个提交不做任何事情，然后合并多个分支是完全正确的。 事实上，当您查看历史logging时，您有一个合并提交并结合分支的事实，这一点非常明确。 与重新分配相比，合并还可以让您有效地查看原始历史logging，包括共存的实际分支。
所以，长话短说：是的，合并提交是完全正确的，你不应该担心他们。
这个答案已经被修改了，因为我的理解，图表和结论是不正确的。
git pull导致合并提交，因为git正在合并。 这可以通过设置你的分支来改变，而不是合并使用rebase。 使用rebase而不是合并pull提供了一个更加线性的历史logging到共享库。 另一方面，合并提交显示分支上的并行开发工作。
例如，两个人在同一个分支上工作。 分支开始为：
...->C1
第一个人完成他们的工作，并推动分支：
...->C1->C2
第二个人完成工作，想推，但不能，因为他们需要更新。 第二个人的本地存储库如下所示：
...->C1->C3
如果pull被设置为合并，则第二个人仓库将如下所示。
...->C1->C3->M1 \ / ->C2->
M1是合并提交。 这个新的分支历史将推到回购。 如果相反，拉动设置为rebase本地回购将如下所示：
...->C1->C2->C3
没有合并提交。 历史已经变得更加线性。
这两个select反映了分支的历史。 git允许你select你喜欢的历史。
确实有些地方rebase可能导致远程分支的问题。 这不是其中之一。 我们更喜欢使用rebase，因为它简化了一个已经很复杂的分支历史，并显示了相对于共享库的历史版本。
你可以设置branch.autosetuprebase = always让git自动build立你的远程分支，而不是master。
git config --global branch.autosetuprebase always
这个设置会让git为每个远程分支自动创build一个configuration设置：
branch.<branchname>.rebase=true
你可以自己设置你已经设置的远程分支。
git config branch.<branchname>.rebase true
我想感谢@LaurensHolst质疑和追求我以前的发言。 我当然知道更多关于如何使用拉和合并提交的git。
有关合并提交的更多信息，您可以阅读贡献到 ProGit-Book中 的项目 。 私人小组部分显示合并提交。
做一个git pull将插入“合并分支”消息，这正是它所做的。 通过执行git pull，您已经将远程分支合并到本地分支中。
当你做一个git pull并且有冲突的时候，git日志会显示冲突文件的更新来自解决冲突的用户。 我认为这是因为修复冲突的人重新提交文件。
据我所知，这只是git的工作方式，并没有办法绕过它。
重新激活会吹掉git的历史logging，所以你将无法看到合并发生的时间。
你可以做：
git pull --rebase
但是，这将始终将您的更改放在协作者之上。 但是你不会得到任何污染的合并信息。
其实有一个更简单的答案。 只要开发人员B做了他的承诺之前做了拉。 这将阻止这些合并提交，因为它们是由您本地提交的本地回购创build的历史logging引起的，它尝试合并远程回购提交的历史logging。 如果您收到一条消息，说明在执行拉动操作时“改变将被覆盖”，这只是表示您同时触摸了同一个文件，因此：
git stash git pull git stash pop
那么你可以解决任何合并冲突，如果有的话。
