当开发分支与主分支非常不同时管理修补程序？

Question

我正在使用“Git Flow”分支模型，具有主分支和开发分支。我正在开发一个重要的新版本，所以我的开发分支与我的主分支大不相同。这在任何时候需要在master分支上制作热补丁并将其重新合并为开发时都会产生问题。几乎总是有冲突，并且正在变成真正的痛苦。

什么是最好的管理方式？对我来说，手动开发小​​修补程序更改会更容易，然后在准备就绪时将所有内容合并到主服务器中，而无需将主机合并到开发中。这可能吗？

Answer 1

我对这种情况的一般工作流程是创建分支master修复问题。一旦准备就绪，将其合并回master，然后合并master到develop。

这假设您的错误修复几乎是它需要在两个分支中更改的代码之间的一对一。如果是这种情况，你总是可以尝试git merge -s ours master（见man-page）到develop，所以develop分支优先。

我使用类似的流程来管理我正在开发的一个开源项目上的错误修复版本。 master始终位于需要应用错误修复的位置之前，所以我从需要修复的标记创建分支，应用修复和发布，然后重新标记并合并到master。这会由于版本号而导致冲突，但可以使用上面的命令来避免。

希望有所帮助。

Answer 2

获取一些从一个分支到另一个分支的最简单方法是cherry-picking。

假设你在master修补程序有提交哈希HASH并且要采取修补程序到您的devel分支，做一个git checkout devel后跟一个git cherry-pick HASH。而已。

如果你想利用从master所有变成devel，就可以实现与

git checkout devel 
git rebase master 

---

如果你有相反的情况（你在devel分支开发中作出修补程序并且想在devel完全合并到master之前将此修复解决为master），工作流程非常类似。假设修补程序有散列HOTFIX_HASH，这样做：

git checkout master 
git cherry-pick HOTFIX_HASH 

现在，犯存在于master和devel。为了解决这个问题，类型

git checkout devel 
git rebase master 

，并提交将于devel消失，因为它已经存在于master。

Answer 3

我通常遵循这个guide这在大多数情况下非常合适，并避免与市长冲突问题和大更改。

如果你能在feature分行工作，只是之前合并它们在development到release分支的创建（这意味着你实际上是准备释放）...这种方法应该避免最合并的冲突，那么你的经验。

由于分支变更将发生在feature-breaking分支上，所以在此分支被合并到开发中时，您可能只有一次冲突。您也可以随时将development合并到release分支中，以便随时更新。

你也会很酷，合并到development所有hotfix-branch es你有最小或无冲突。

我之前在链接上分享的指南非常重视从不从development到master或向后合并。始终通过release分支处理您的版本。