Git：将分支合并到master，或者master合并到branch

Question

我想知道我是否犯了一个错误，先将 master 合并到另一个分支，然后再将其合并回 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"

现在我想合并。通常，我更喜欢先将master合并到x中，然后再将x合并到master中：

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

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

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

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

Answer 1

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

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

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

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

Git：将分支合并到master，或者master合并到branch

Git: merge branch into master, or master into branch

git

merge

git-merge