假设我有两个分支
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?这有点令人困惑,所以非常感谢一个好的解释
最佳答案
缺少工作流任务
首先,您的工作流程中缺少一些东西,因此很难以真实世界的方式回答您的问题。例如:
在 merge 分支之前,您应该始终从上游 pull 。其他人可能以您未考虑的方式改变了开发或掌握。
您还没有确定哪一条是您的长期发展路线。假设是开发,但这只是一种猜测,因为您还没有确定 merge 后您的分支会发生什么。
rebase 长期分支的一般最佳实践
因此,假设您已经提前更新了分支,并且 master 和 develop 都是长期存在的分支,并且 master 是完整代码的“官方”分支,那么您应该按照这些思路做一些事情。
基于 develop 创建一个临时的 rebase 分支。
git checkout -b tmp develop
将您的工作重新定位到 master 以确保干净的快进 merge 。我喜欢把它做成一个交互式的 rebase ,但你可以随心所欲地做。例如:
git rebase -i master
merge 到 master。我更愿意强制 merge 快进,但您可以做任何适合您的事情。
git checkout master git merge --ff-only tmp
确保 merge 的分支干净地推送。
git push origin
如果一切顺利,处置您的临时分支。
git branch -d tmp
将 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 付出的代价是值得的。
关于git - 用什么方式和git merge ?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/11561795/