Git：将分支合并到主分支，或将主分支合并到分支

Question

我在想，先将主分支合并到另一个分支，再将它合并回主分支是否会犯错。

假设我创建了以下分支，并且每个分支都有单独的提交记录：

            mkdir git_merging
            cd git_merging/
            git init
            touch on_master
            git add .
            git commit -m "Initial commit on master"

            git checkout -b x
            touch on_branch_x
            git add .
            git commit -m "Initial commit on branch x"

            git checkout master
            touch on_master_again
            git add .
            git commit -m "Commit on master after branching"

现在我想要合并。通常，我喜欢先将主分支(master)合并到x分支中，然后再将x分支合并回主分支(master):

            git checkout x
            git merge -m "Merge master into x" master 
            echo "test results"
            git checkout master 
            git merge x

这样我就可以在将更改合并回主分支之前测试它们，确保我始终拥有一个可用的主分支。就我所知，与将x直接合并到主分支相比，没有功能上的区别：

            git merge -m "Merge x into master" x
            git checkout x 
            git merge master 

实际上，我经常遇到似乎只将分支合并回主分支的代码库。我的方法有什么缺点吗？为什么不应该这样做呢？

- jdoestackoverflow

Answer 1

这是一个非常主观的问题，但我认为我可以给出比较客观的答案。

在合并分支之前将主分支合并回来是一个很好的实践。如果有人提交了一些破坏你刚刚实现的功能的东西（正如你指出的那样），又或者有人修改了你编写的代码，导致可能出现合并冲突，你应该怎么办呢？我建议将主分支定期合并回你的分支中。这不仅可以避免花费一天半时间解决合并冲突（虽然，这可能表明你的分支太大了，但这是另一个故事），而且还能让你随着项目的变化和发展保持一致。

有些人可能会说你应该在主分支上进行变基。我的简短版本是：我鼓励人们在开发过程的早期就打开拉取请求，即使某个功能尚未完成。这意味着你可能会把你的代码推送到一个远程服务器（如GitHub）。为了对你的提交进行变基，你将不得不使用重写的git历史记录推送，并强制推送。强制推送是一个糟糕的工作流决策，应该避免，因为它可能会对你的提交历史造成（几乎）永久性的损害。

因此，在你打算合并时最好在合并之前从主分支合并回来，否则尽可能经常地这样做。如果你使用GitHub，我甚至鼓励使用新的Protected Branches功能强制在合并前更新分支:

- Kyle Macey