说我有两个分支
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
如果我现在在融合发展或进入主？ 这是一个有点混乱，所以一个很好的解释将非常感激
首先，有几件事情在您的工作流程缺少使它很难回答现实世界的方式你的问题。 例如：
你应该总是从上游合并分支前拉。 其他人可能已经改变开发或船长 ，你还没有占到方式。
您还没有确定这是你的长寿命发展的路线。 一个假设的发展 ，但是这只是一个猜测，因为你还没有确定合并后如何处理自己的分支机构。
因此，假设你已经提前更新你的分支，并且掌握和发展都是长寿分公司和master是完成代码“官方”的分支，那么你应该做的东西沿着这些路线。
请根据发展临时衍合分支。
git checkout -b tmp develop 衍合你的工作在主 ，以确保干净的快进合并。 我想使这是一个互动的底垫，但做任何你想要的方式。 例如：
git rebase -i master 合并到主 。 我宁愿强制合并是一个快进，但你可以做任何适合你。
git checkout master git merge --ff-only tmp 确保合并后的分支干净推动。
git push origin 如果一切顺利，处置您的临时党支部的。
git branch -d tmp 重新合并主与发展作为合并提交，而不是快进。 这使你的发展与主分支的继续工作线。
git checkout develop git merge master git push origin 这样做可以确保在master分支的历史是从合并冲突相对线性的和免费的，而且还可以让你在需要的时候没有搞砸了分公司公布重订。 这都是积极的东西。
然而，这个过程可以留下，因为从主重新合并发展可能并不总是快进合并复杂的合并历史发展 。 这是不是问题本身，它是一个包含重订基期的任何工作流程只是一个自然的结果。 这是一个需要注意的，但在我看来这是值得为它付出代价提供了团队的灵活性的代价。
做第二次，合并，而在大师。
我通常重订主原点，底垫开发掌握， 然后合并。 这使得底垫在冲突出现; 如果你这样做，不会有合并冲突。
