Git pull 在提交日志中产生无关的“合并分支”消息

Git pull results in extraneous "Merge branch" messages in commit log

提问by mshafrir

I'm working with another developer on a project, and we're using Github as our remote repo. I'm on a Mac using git 1.7.7.3, he's on Windows using git 1.7.6.

我正在与另一个开发人员合作开发一个项目，我们使用 Github 作为我们的远程存储库。我在 Mac 上使用 git 1.7.7.3，他在 Windows 上使用 git 1.7.6。

This is what's happening

这就是正在发生的事情

1. One of us (let's call him developer A, but it doesn't matter which one) pushes a set of commits to GitHub.
2. The other (developer B) makes some local commits.
3. B does a git pull.
4. B does a git push.
5. Looking at the commit history log, I see Merge branch 'master' of github.com:foo/bar

1. 我们中的一个人（我们称他为开发人员 A，但不管是哪一个）将一组提交推送到 GitHub。
2. 另一个（开发人员 B）进行一些本地提交。
3. B 做一个git pull.
4. B 做一个git push.
5. 查看提交历史日志，我看到github.com:foo/bar 的 Merge branch 'master'

The commit log gets littered with "Merge branch" messages over time, and also shows developer B as committing changes that developer A made. The only way we've found to prevent this issue has been to do a git pull --rebaseat step 3, but I don't know what side effects rebasing will introduce. This is my first time working on a multi-developer git repo, so is this just normal behavior? Any thoughts on how to solve this issue?

随着时间的推移，提交日志中充斥着“合并分支”消息，并且还显示开发人员 B 正在提交开发人员 A 所做的更改。我们发现防止此问题的唯一方法是git pull --rebase在第 3 步执行 a ，但我不知道变基会带来什么副作用。这是我第一次在多开发人员 git 存储库上工作，所以这只是正常行为吗？关于如何解决这个问题的任何想法？

采纳答案by poke

The commit you are seeing is perfectly fine. A pulleffectively runs git fetchand then git mergeso a merge is usually happening when you run git pull.

您看到的提交非常好。Apull有效地运行git fetch，然后git merge当您运行时通常会发生合并git pull。

The alternative to use rebasing instead of merging is possible, but usually you should avoid it. Rebasing allows you to keep a linear history, but also removes any information about the branching that originally happened. It will also cause the history of the current branch being rewritten, recreating all commits that are not contained in the target branch (in your case, the remote). As the recreated commits are differentcommits, this can cause a lot of confusion when developing together with others, especially when people already checked out parts of those commits before they get rewritten (for example with feature branches). So as a rule of thumb, you should neverrewrite any commit that was already pushed.

使用变基代替合并的替代方法是可能的，但通常您应该避免它。变基允许您保留线性历史记录，但也会删除有关最初发生的分支的任何信息。它还将导致当前分支的历史记录被重写，重新创建目标分支（在您的情况下，远程）中未包含的所有提交。由于重新创建的提交是不同的提交，当与其他人一起开发时，这可能会导致很多混乱，尤其是当人们在重写之前已经检查了这些提交的部分（例如使用功能分支）时。所以根据经验，你永远不应该重写任何已经推送的提交。

The commits you see are there to combine two (or more) branches. It is perfectly fine to have a commit that does nothing else then merging multiple branches. In fact it makes it very clear when you have a merge commit that combines branches when looking at the history. In comparison to rebasing, merging also allows you to effectively see the originalhistory as it was developed, including the actual branches that coexisted.

您看到的提交用于合并两个（或多个）分支。提交一个什么都不做然后合并多个分支的提交是完全没问题的。事实上，当您在查看历史记录时有一个合并分支的合并提交时，它会非常清楚。与变基相比，合并还可以让您在开发时有效地查看原始历史记录，包括共存的实际分支。

So, long story short: Yes, having merge commits is perfectly fine and you should not worry about them.

所以，长话短说：是的，合并提交非常好，您不必担心它们。

回答by Bill Door

This answer has been revised, as my understanding, diagrams, and conclusions were incorrect.

这个答案已被修改，因为我的理解、图表和结论是不正确的。

---

---

git pullcauses merge commits because git is merging. This can be changed by setting your branches to use rebase instead of merge. Using rebase instead of merge on a pull provides a more linear history to the shared repository. On the other hand, merge commits show the parallel development efforts on the branch.

git pull导致合并提交，因为 git 正在合并。这可以通过将分支设置为使用 rebase 而不是合并来更改。在 pull 上使用 rebase 而不是 merge 为共享存储库提供了更线性的历史记录。另一方面，合并提交显示了分支上的并行开发工作。

For example, two people are working on the same branch. The branch starts as:

例如，两个人在同一个分支上工作。分支开始为：

...->C1

The first person finishes their work and pushes to the branch:

第一个人完成工作并推送到分支：

...->C1->C2

The second person finishes their work and wants to push, but can't because they need to update. The local repository for the second person looks like:

第二个人完成了他们的工作并想推送，但不能因为他们需要更新。第二个人的本地存储库如下所示：

...->C1->C3

If the pull is set to merge, the second persons repository will look like.

如果 pull 设置为合并，则第二个人存储库将如下所示。

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

Where M1 is a merge commit. This new branch history will be pushed to the repo. If instead, the pull is set to rebase the local repo would look like:

其中 M1 是合并提交。这个新的分支历史将被推送到 repo。如果相反，pull 设置为 rebase，本地 repo 将如下所示：

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

There is no merge commit. The history has been made more linear.

没有合并提交。历史变得更加线性。

Both choices reflect the history of the branch. git allows you to choose which history you prefer.

这两种选择都反映了分支的历史。git 允许您选择您喜欢的历史记录。

There are indeed places where rebase can cause a problem with remote branches. This is not one of those cases. We prefer to use rebase as it simplifies an already complicated branch history as well as shows a version of the history relative to the shared repository.

确实在某些地方 rebase 会导致远程分支出现问题。这不是其中一种情况。我们更喜欢使用 rebase，因为它简化了已经很复杂的分支历史，并显示了相对于共享存储库的历史版本。

You can set branch.autosetuprebase=always to have git automatically establish your remote branches as rebase instead of master.

您可以设置 branch.autosetuprebase=always 让 git 自动将远程分支建立为 rebase 而不是 master。

git config --global branch.autosetuprebase always

This setting causes git to automatically create a configuration setting for each remote branch:

此设置使 git 自动为每个远程分支创建配置设置：

branch.<branchname>.rebase=true

You can set this yourself for your remote branches that are already setup.

您可以为已经设置的远程分支自行设置。

git config branch.<branchname>.rebase true

---

---

I would like to thank @LaurensHolst for questioning and pursuing my previous statements. I have certainly learned more about how git works with pull and merge commits.

我要感谢@LaurensHolst 对我之前的陈述提出质疑和追问。我当然已经了解了更多关于 git 如何处理 pull 和 merge 提交的知识。

For more information about merge commits you can read Contributing to a Projectin ProGit-Book. The Private Small Teamsection shows merge commits.

有关合并的提交，你可以阅读更多的信息为一个项目贡献在ProGit图书。在私人小团队部分显示合并的提交。

回答by gaborous

You can do:

你可以做：

git pull --rebase

However, this will always put your changes on top of your collaborators'. But you won't get any polluting merge message.

但是，这将始终将您的更改置于您的合作者之上。但是您不会收到任何污染合并消息。

回答by Luke

There is actually a much simpler answer to this. Just have developer B do a pull BEFORE making his commit. This will prevent those merge commits, since they're caused by the history you've created on your local repo from your local commit trying to merge with the history of the commits on the remote repo. If you get a message saying something along the lines of 'changes will be overwritten' when doing a pull, it just means you both touched the same file, so do:

对此，实际上有一个更简单的答案。在提交之前让开发人员 B 做一个 pull 。这将阻止这些合并提交，因为它们是由您在本地存储库上创建的历史记录导致的，而您的本地提交尝试与远程存储库上的提交历史记录合并。如果您在执行拉取操作时收到一条消息，说“更改将被覆盖”之类的话，这仅意味着你们都接触了同一个文件，所以这样做：

git stash
git pull
git stash pop

then you can resolve any merge conflicts if there are any.

那么您可以解决任何合并冲突（如果有的话）。

回答by kclair

Doing a git pull will insert the "Merge branch" messages, that's just what it does. By doing a git pull, you have merged the remote branch into your local branch.

执行 git pull 将插入“合并分支”消息，这就是它的作用。通过执行 git pull，您已将远程分支合并到本地分支中。

When you do a git pull and there are conflicts, the git log will show the updates to the conflicted files as coming from the user that resolved the conflicts. I assume this is because the person that fixes the conflict re-commits the file.

当您执行 git pull 并且存在冲突时，git log 会将冲突文件的更新显示为来自解决冲突的用户。我认为这是因为解决冲突的人重新提交了文件。

As far as I know that's just how git works, and there is not a way around it.

据我所知，这就是 git 的工作方式，而且没有办法绕过它。

Rebasing will blow away the git history, so you won't be able to see when merges occurred.

变基会清除 git 历史记录，因此您将无法看到合并发生的时间。