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" 

现在我想合并。通常情况下，我更喜欢先合并掌握到x，然后对x合并到主：

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

这样合并到master，确保我总是有一个正常运作的主分支之前，我可以测试的东西。据我所知，没有任何功能上的差别，相比于直接合并x转换成主：

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

在实践中，我经常会遇到，似乎完全合并到主然而库。我的方法有什么缺点吗？任何我不应该这样做的原因？

Answer 1

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

这是一个伟大的练习合并主副本到您的分支合并之前。如果其他人犯了破坏刚才实现的功能的东西（正如你指出的那样）？或者如果某人修改了您所做的相同代码并导致了可能的合并冲突？我实际上建议非常频繁地将主人合并回分支。这不仅会让你不得不花费一天半的时间来解决合并冲突（尽管这可能表明你的分支机构太大了，但这是另一回事），但它也可以让你随着项目的变化而保持一致演变。

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

所以，是的，在你合并之前从主人合并回来，并且你可以以其他方式经常合并。如果你使用GitHub上，我甚至鼓励使用新的受保护的分支功能来合并之前执行与主更新分支：