Git pull导致无关的“合并分支"提交日志中的消息
我正在与另一位开发人员合作开发一个项目，我们使用 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.
这是怎么回事
- 我们中的一个人(我们称他为开发人员 A，但不管是哪一个)将一组提交推送到 GitHub.
- 另一个(开发人员 B)进行一些本地提交.
- B 做了一个
git pull. - B 做了一个
git push. - 查看提交历史日志，我看到合并github.com:foo/bar的分支'master'
随着时间的推移，提交日志中充斥着合并分支"消息，并且还显示开发人员 B 正在提交开发人员 A 所做的更改.我们发现防止此问题的唯一方法是在第 3 步执行 git pull --rebase，但我不知道变基会带来什么副作用.这是我第一次在多开发人员 git repo 上工作，所以这只是正常行为吗?关于如何解决这个问题的任何想法?
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 所以当你运行 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.