git - 用什么方式和git merge ？

Question

假设我有两个分支

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

现在如果我想 merge 它会快进，但我应该这样做吗

git checkout develop
git merge master

或

git checkout master
git merge develop

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

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

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

Answer 1

缺少工作流任务

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

1. 在 merge 分支之前，您应该始终从上游 pull 。其他人可能以您未考虑的方式改变了开发或掌握。

2. 您还没有确定哪一条是您的长期发展路线。假设是开发，但这只是一种猜测，因为您还没有确定 merge 后您的分支会发生什么。

rebase 长期分支的一般最佳实践

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

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

   git checkout -b tmp develop
   

2. 将您的工作重新定位到 master 以确保干净的快进 merge 。我喜欢把它做成一个交互式的 rebase ，但你可以随心所欲地做。例如:

   git rebase -i master
   

3. merge 到 master。我更愿意强制 merge 快进，但您可以做任何适合您的事情。

   git checkout master
   git merge --ff-only tmp
   

4. 确保 merge 的分支干净地推送。

   git push origin
   

5. 如果一切顺利，处置您的临时分支。

   git branch -d tmp
   

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

   git checkout develop
   git merge master
   git push origin
   

自然后果

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

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