在提交日志中,Git pull导致无关的“合并分支”消息

我正在与一个项目的另一个开发人员合作,我们使用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的合并分支“主”

随着时间的推移,提交日志充斥着“合并分支”消息,并且还显示开发者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 

那么你可以解决任何合并冲突,如果有的话。