Git:将分支 merge 到master，或将master merge 到分支

Question

我想知道我是否犯了一个错误，首先将 master merge 到另一个分支，然后再将它 merge 回 master。

假设我创建了以下分支，每个分支都有一个单独的提交:

            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"

现在我想 merge 。通常，我更喜欢先将 master merge 到 x，然后再将 x merge 到 master:

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

这样我就可以在 merge 回 master 之前进行测试，确保我始终有一个正常运行的 master 分支。据我所知，与将 x 直接 merge 到 master 相比，没有功能差异:

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

在实践中，我经常遇到似乎专门 merge 回 master 的存储库。我的方法有什么缺点吗？为什么我不应该这样做？

Answer 1

这是一个相当主观的问题，但我会通过，因为我认为我可以得出一个相当客观的答案。

在 merge 之前将 master merge 回您的分支是一个很棒的做法。如果其他人破坏了您刚刚实现的功能(如您所指出的)怎么办？或者，如果有人修改了您所做的相同代码，并导致可能的 merge 冲突怎么办？我实际上建议非常频繁将 master merge 回您的分支。这不仅可以避免您不得不花一天半的时间来解决 merge 冲突(尽管，这可能表明您的分支太大，但这是另一回事)，而且还可以让您在项目更改和进化。

有些人可能会说你应该rebase你的提交在 master 之上。我的简短版本是:我鼓励人们在开发过程的早期就打开 pull 请求，即使一个功能还没有完成。这意味着您可能会将代码推送到远程服务器(例如 GitHub)。为了 rebase 你的提交，你必须使用重写的 git 历史来推送，并强制推送。强制推送是一个糟糕的工作流程决策，应该避免，因为它可能(几乎)对您的提交历史造成永久性损害。

所以是的，在你要 merge 之前就从 master merge 回来，否则尽可能多地 merge 。如果您使用 GitHub，我什至鼓励使用新的 protected 分支功能来强制在 merge 之前使用 master 更新分支: