Git pull导致无关的“合并分支”提交日志中的消息 [英] Git pull results in extraneous "Merge branch" messages in commit log

问题描述

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

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.

这就是发生了什么

1. 我们中的一个人（让我们称他为开发人员A，但哪一个并不重要）将一组提交推送给GitHub。 其他（开发者B）进行一些本地提交。


2. B执行 git pull 。


3. B做了一个 git push 。


4. 查看提交历史日志，我看到合并分支'master' github.com:foo/bar

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

随着时间的推移，提交日志充斥着合并分支消息，显示开发者B提交了开发者A所做的更改。我们发现防止这个问题的唯一方法是在步骤3执行 git pull --rebase ，但我不知道rebasing将引入什么副作用。这是我第一次开发一个多开发人员的git仓库，那么这只是正常的行为？关于如何解决这个问题的任何想法？

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 --rebase at 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?

推荐答案

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

The commit you are seeing is perfectly fine. A pull effectively runs git fetch and then git merge so a merge is usually happening when you run 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 different commits, 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 never rewrite 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 original history 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.

这篇关于Git pull导致无关的“合并分支”提交日志中的消息的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！