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

Question

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

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

Answer 1

从一个分支到另一个分支的最简单的提交方式是cherry-picking。

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

如果您想将所有更改从masterinto devel，您可以通过以下方式实现

git checkout devel
git rebase master

---

如果您有相反的情况（您在开发期间在devel分支中制作了一个修补程序，并希望在完全合并到master之前将该修补程序纳入），则工作流程非常相似。假设修补程序具有 hash ，请执行以下操作：develmasterHOTFIX_HASH

git checkout master
git cherry-pick HOTFIX_HASH

现在，提交存在于masterand中devel。要解决此问题，请键入

git checkout devel
git rebase master

并且提交将从中消失，devel因为它已经存在于master.

Answer 2

My general workflow for this situation is to create a bug-fix branch of master that fixes the problem. Once it's ready, merge that back into master then merge master into develop.

This assumes that your bug fix is almost a one-to-one between the code it needs to change in both branches. If that's the case, you could always try a git merge -s ours master (see man-page) into develop so the develop branch takes priority.

I use a similar process for managing bug fix releases on an open-source project I'm working on. master is always ahead of where the bug fix needs to be applied, so I create a branch from the tag that needs the fix, apply the fix and release, then retag and merge the new tag into master. This causes a conflict because of the version numbers, but can be avoided with the command above.

Hope that helps.

Answer 3

我通常遵循本指南，该指南在大多数情况下都非常适合，并避免出现冲突和重大变化的问题。

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

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

你也会很酷地合并到你拥有的development所有hotfix-branches 中，并且完全没有冲突。

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

Answer 4

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

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