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

Question

我使用的是“Git Flow”分支模型，有一个主分支和一个开发分支。我正在开发一个主要的新版本，所以我的开发分支与我的主分支大不相同。每当我需要在主分支上进行修补程序并将其合并回开发时，这都会产生问题。几乎总是有冲突，这正在成为一种真正的痛苦。

管理此问题的最佳方法是什么？对我来说，手动对开发进行小的修补程序更改会更容易，然后在我准备好时将所有内容合并到主控中，而无需将主控重新合并到开发中。这可能吗？

Answer 1

获得一些从一个分支到另一个分支的提交的最简单方法是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 2

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

这假设您的错误修复几乎是在两个分支中需要更改的代码之间的一对一关系。如果是这种情况，您可以随时尝试将git merge -s ours master（参见man-page）转换为develop，以便develop 分支优先。

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

希望对您有所帮助。

Answer 3

我通常遵循这个guide，它在大多数情况下都非常适合，并且避免了冲突和大变化的市长问题。

如果您可以在 feature 分支上工作并仅在创建 release 分支之前将它们合并到 development 中（这意味着您实际上正在准备发布）...这种方法应该可以避免大多数合并冲突您经验。

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

您还可以将所有hotfix-branches 合并到development 中，并且冲突最少或完全没有冲突。

我之前在链接上分享的指南非常强调永远不要从 development 合并到 master 或向后合并。始终通过release 分支处理您的发布。

Answer 4

这一切都取决于您将如何使用 GIT 来管理您的代码、发布计划和版本。最好的做法是让master 分支来保存你的生产级代码，让develop 分支来做你的开发，让release 分支从develop 分支出来来处理你即将发布的版本，hotfix 分支从master 处理生产代码的紧急修复。所以release 和hotfix 分支最终将合并回master 和develop 以确保两个分支都有更改，稍后develop 分支出新的release 这个新版本有在master 上合并没问题。并且标记将始终在master。

使用这种方法，release 和hotfix 分支会被合并两次，在合并到develop 时有时会出现冲突，如果有很多开发活动正在进行develop，这是不可避免的。缩短您的 release 或 hotfix 分支生命周期可能是缓解此问题的一种方法。如果发生冲突，请使用任何技术解决它，并确保不要更改已完成和测试的 release 或 hotfix 代码。