Git：将分支合并为master，或者master转换为分支

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 

在实践中，我经常会遇到似乎完全合并回主人的存储库。我的方法有什么缺点吗？我不应该这样做的任何理由？

Answer 1

这是一个非常主观的问题，但我会给它一个通行证，因为我认为我可以提出一个相当客观的答案。

在合并之前将master合并回分支是一种很棒的做法。如果其他人犯下了破坏您刚刚实施的功能的内容（正如您所指出的），该怎么办？或者如果有人修改了您所做的相同代码，并导致可能的合并冲突怎么办？我实际上建议将master重新合并到你的分支非常频繁。这不仅可以防止您花费一天半的时间来解决合并冲突（但是，这可能表明您的分支机构太大，但这是另一个故事），但它也会让您在项目更改时保持一致演变。

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

所以是的，在你看到合并之前从主人那里合并回来，并且尽可能经常。如果您使用GitHub，我甚至鼓励使用新的受保护分支功能强制在合并之前使用master更新分支：