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

我现在应该合并开发还是成为高手？这有点令人困惑,所以一个很好的解释将非常感激

Answer 1

缺少工作流程任务

首先,您的工作流程中缺少一些内容,使您难以以真实的方式回答您的问题.例如:

1. 在合并分支之前,应始终从上游拉出.其他人可能会以你没有考虑到的方式改变发展或掌握.

2. 您还没有确定哪个是您长期以来的发展方向.一个假定开发,但这只是猜测,因为你没有确定合并后你的分支发生了什么.

重新定位长期分支机构的一般最佳实践

因此,假设您已经提前更新了分支,并且master和develop都是长期分支,而master是完成代码的"官方"分支,那么您应该沿着这些方向做一些事情.

1. 根据开发制作临时的变基分支.

   git checkout -b tmp develop
   

2. 将您的工作重新定位到master上以确保干净的快进合并.我喜欢把它变成一个互动的rebase,但是你想做任何你想做的事.例如:

   git rebase -i master
   

3. 合并到主人.我更愿意强制合并为快进,但你可以做任何适合你的事情.

   git checkout master
   git merge --ff-only tmp
   

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

   git push origin
   

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

   git branch -d tmp
   

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

   git checkout develop
   git merge master
   git push origin
   

自然后果

这样做可以确保主分支上的历史记录相对线性且没有合并冲突,并且仍然允许您在需要时进行变基,而不会搞砸已发布的分支.这都是积极的事情.

但是,由于从master到develop的重新合并可能并不总是快速合并,因此这个过程可以使开发具有复杂的合并历史.这本身不是问题,它只是包括变基在内的任何工作流程的自然结果.这是值得注意的事情,但在我看来,它为团队提供的灵活性付出了代价.