git - 哪种方式与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

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

score 6 · Accepted Answer

首先，您的工作流程中缺少一些东西，这使得您很难以现实世界的方式回答您的问题。例如：

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

建立一个基于develop的临时变基分支。
```
git checkout -b tmp develop
```
将您的工作重新定位到master以确保干净的快进合并。我喜欢把它变成一个交互式的变基，但可以按照你想要的方式做。例如：
```
git rebase -i master
```
合并到master。我更喜欢强制合并快进，但你可以做任何适合你的事情。
```
git checkout master
git merge --ff-only tmp
```
确保合并的分支干净利落地推送。
```
git push origin
```
如果一切顺利，请处置您的临时分支机构。
```
git branch -d tmp
```
将master与develop重新合并为合并提交，而不是快进。这使您的开发与主分支保持一致，以便继续工作。
```
git checkout develop
git merge master
git push origin
```

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

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

score 3 · Accepted Answer

做第二个，在master中合并。

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

2 回答 2