开发分支时管理修补程序与master有很大不同？

Question

我正在使用"Git Flow"分支模型,主分支和开发分支.我正在开发一个主要的新版本,所以我的开发分支与我的主分支完全不同.每当我需要在主分支上创建一个修补程序并将其合并回develop时,这就会产生问题.几乎总是存在冲突,它正在成为一种真正的痛苦.

管理这个的最佳方法是什么？我可以更容易地手动开发小​​修补程序,然后在我准备好时将所有内容合并到master中,而不将master重新合并到develop中.这可能吗？

Answer 1

从一个分支到另一个分支的一些提交的最简单方法是挑选.

假设您的修复程序master具有提交哈希,HASH并且您希望将该修补程序带入您的devel分支,请执行a git checkout devel后跟a git cherry-pick HASH.而已.

如果你想利用一切从改变master到devel,就可以实现与

git checkout devel
git rebase master

如果你有相反的情况(你在devel分支开发期间制作一个修补程序,并希望master在devel完全合并之前将该修复程序放入master),则工作流程非常相似.假设此修补程序具有哈希HOTFIX_HASH,请执行以下操作:

git checkout master
git cherry-pick HOTFIX_HASH

现在,提交存在于master和devel.要解决此问题,请键入

git checkout devel
git rebase master

devel因为它已经存在,所以提交将从中消失master.

Answer 2

我对这种情况的一般工作流程是创建一个解决问题的bug-fix分支master.一旦准备就绪,将其合并回master然后合并master成develop.

这假设您的错误修复几乎是两个分支中需要更改的代码之间的一对一.如果是这种情况,您可以随时尝试git merge -s ours master(参见手册页),develop以便develop分支优先.

我使用类似的过程来管理我正在开发的开源项目上的错误修复版本. master总是领先于需要应用错误修复的地方,所以我从需要修复的标记创建一个分支,应用修复和发布,然后重新标记并合并新标记master.由于版本号,这会导致冲突,但可以使用上面的命令避免冲突.

希望有所帮助.

Answer 3

我通常遵循这个指南,这在大多数情况下非常适合,避免了市长对冲突和重大变化的问题.

如果你可以在feature分支上工作并且development只在release分支创建之前合并它们(意味着你实际上正准备发布)...这种方法应该避免你遇到的大多数合并冲突.

由于在feature-breaking分支处发生了重大更改,因此在将此feature-breaking分支合并到开发中时,您可能只会遇到一次冲突.您也可以随时合并development到release分支机构以保持更新.

你也可以很好地融入development所有hotfix-branch你拥有的最小或非冲突的es.

我之前在链接上分享的指南非常强调从不合并development到master倒退.始终通过release分支处理您的版本.