Git：将分支合并到主控，或将主控合并到分支答案

【问题标题】：Git: merge branch into master, or master into branchGit：将分支合并到主控，或将主控合并到分支
【发布时间】：2017-02-26 22:00:50
【问题描述】：

我想知道我是否犯了一个错误，首先将 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 的存储库。我的方法有什么缺点吗？为什么我不应该这样做？

【问题讨论】：

标签： git merge git-merge

【解决方案1】：

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

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

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

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

【讨论】：