哪种方式与git合并？

Question

假设我有两个分支

master -- A -   -   -   -   -  - merge
          \                    /
           \- develop -- B -- C

现在如果我想合并它会是一个快进，但我应该这样做

git checkout develop
git merge master

或

git checkout master
git merge develop

如果我有可能的冲突怎么办

master -- A - D -  -  -  -  -  -merge
          \                   /
           \- develop -- B -- C

我现在应该合并到develop还是master？这有点令人困惑，所以非常感谢一个好的解释

Answer 1

缺少工作流任务

首先，您的工作流程中缺少一些东西，因此很难以真实的方式回答您的问题。例如：

1. 在合并分支之前，您应该始终从上游拉取。其他人可能以您没有考虑到的方式更改了 develop 或 master。

2. 您尚未确定哪个是您的长期发展路线。假设 develop，但这只是一种猜测，因为您还没有确定在合并之后 分支会发生什么。

重新定位长期存在的分支的一般最佳实践

所以，假设您提前更新了分支，并且 master 和 develop 都是长期存在的分支并且 master em> 是完整代码的“官方”分支，那么你应该按照这些思路做一些事情。

1. 基于develop创建一个临时变基分支。

   git checkout -b tmp develop
   

2. 将您的工作重新定位到 master 以确保干净的快进合并。我喜欢把它变成一个交互式的变基，但可以按照你想要的方式做。例如：

   git rebase -i master
   

3. 合并到 master。我更喜欢强制合并快进，但你可以做任何适合你的事情。

   git checkout master
   git merge --ff-only tmp
   

4. 确保合并后的分支推送干净。

   git push origin
   

5. 如果一切顺利，请处理掉你的临时分支。

   git branch -d tmp
   

6. 重新合并 master 与 develop 作为合并提交，而不是快进。这将使您的开发与 master 分支保持一致，以便继续工作。

   git checkout develop
   git merge master
   git push origin
   

自然后果

这样做可以确保您的 master 分支上的历史记录是相对线性的并且没有合并冲突，并且仍然允许您在需要时重新设置基准，而不会搞砸已发布的分支。这都是积极的东西。

但是，此过程可能会给 develop 留下复杂的合并历史，因为从 master 重新合并到 develop 可能并不总是快进合并。这本身不是问题，它只是任何包含变基的工作流的自然结果。这是需要注意的事情，但在我看来，它为团队提供的灵活性值得付出代价。

Answer 2

做第二个，在master中合并。

我通常 rebase master 到 origin，rebase dev 到 master，然后合并。这使得冲突在变基期间出现；如果你这样做，就不会有合并冲突。