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

我正在使用带有主分支和开发分支的“ Git Flow”分支模型。我正在开发一个主要的新版本，因此我的developer分支与我的master分支完全不同。每当我需要在master分支上进行修复并将其合并回developer中时，这都会造成问题。几乎总是有冲突，这正成为一种真正的痛苦。

最好的管理方式是什么？对我而言，手动更改开发中的较小修补程序会比较容易，然后在我准备好时将所有内容合并到master中，而无需将master重新合并到development中。这可能吗？

从一个分支到另一个分支获取某些提交的最简单方法是挑选樱桃。

假设您的修复程序中master包含提交哈希，HASH并且您想将该修补程序带入devel分支中，请执行，git checkout devel后跟一个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。

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

假设您的错误修复几乎是两个分支都需要更改的代码之间的一对一。如果是这种情况，您总是可以尝试使用git merge -s ours master（请参见man-page），develop以便develop分支具有优先权。

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

希望能有所帮助。

我通常会遵循该指南，该指南非常适合大多数情况，并且避免了市长遇到冲突和重大变化的问题。

如果您可以在feature分支上工作并development仅在release创建分支之前将它们合并（这意味着您实际上正在准备发行），则此方法应避免您遇到的大多数合并冲突。

由于feature-breaking分支会发生重大更改，因此在该feature-breaking分支合并到开发中时，您可能只会发生一次冲突。您也可以随时合并development到release分支中以保持更新。

您也将很冷静地将自己的development所有功能合并到hotfix-branch最少或完全没有冲突的状态。

我之前在链接上共享的指南非常强调从不development进行master反向合并。始终通过release分支机构处理发布。

这一切都取决于您将如何使用GIT来管理代码，发布计划和版本。最佳实践是让master分支机构保存您的生产级别代码，让develop分支机构进行您的开发，从release分支机构分支develop来处理您即将发布的版本，hotfix从分支机构分支master来处理生产代码的紧急修复。因此，releaseandhotfix分支最终将合并回BOTH master，develop并确保两个分支都进行了更改，并且稍后在develop分支出新版本时，release此新发行版将没有问题可以合并master。并且标记将始终处于打开状态master。

使用这种方法，releaseandhotfix分支将合并两次，并且在合并时有时会看到冲突develop，如果正在进行许多开发活动，这是不可避免的develop。缩短您release或hotfix分支机构的生命周期可能是减轻此问题的一种方法。如果发生矛盾，与任何技术解决，并确保不改变完成并经过测试release或hotfix代码。