开发分支时管理修补程序与主分支有很大不同？
我正在使用“Git Flow”分支模型，带有一个主分支和一个开发分支。我正在开发一个主要的新版本，所以我的开发分支与我的主分支有很大不同。每当我需要在主分支上进行修补程序并将其合并回开发中时，这都会产生问题。冲突几乎总是存在，这正成为一种真正的痛苦。
管理这个问题的最佳方法是什么？对我来说，手动对开发进行小的修补程序更改，然后在准备好时将所有内容合并到主控中，而不将主控合并回开发中会更容易。这可能吗？
I'm using the "Git Flow" branching model, with a master branch and a develop branch. I'm working on a major new release, so my develop branch is wildly different from my master branch. This creates a problem anytime I need to make a hotfix on the master branch and merge it back into develop. There are almost always conflicts, and it's becoming a real pain.
What is the best way to manage this? It would be easier for me to make the small hotfix changes on develop manually and then merge everything into master when I'm ready without merging master back into develop. Is this possible?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
将一些提交从一个分支转移到另一个分支的最简单方法是精挑细选。
假设您在
master中的修复程序具有提交哈希HASH并且您希望将该修补程序放入您的devel分支中，请执行git checkout devel后跟gitcherry-pick HASH。就是这样。如果您想将 所有 更改从
master更改为devel，则可以通过以下方式实现：如果您有相反的情况（您在在
devel分支中进行开发，并希望在devel完全合并到master之前将该修复引入到master中），工作流程非常相似。假设修补程序具有哈希值HOTFIX_HASH，请执行以下操作：现在，提交存在于
master和devel中。为了解决这个问题，请输入内容，提交将从
devel中消失，因为它已经存在于master中。The simplest way to get some commits from one branch to another is cherry-picking.
Assuming that your fix in
masterhas the commit hashHASHand you want to take that hotfix into yourdevelbranch, do agit checkout develfollowed by agit cherry-pick HASH. That's it.If you want to take all changes from
masterintodevel, you can achieve that withIf you have the opposite scenario (you make a hotfix during development in a
develbranch and want to take that fix intomasterbeforedevelgets fully merged intomaster), the workflow is quite similar. Assuming that the hotfix has the hashHOTFIX_HASH, do this:Now, the commit is present in
masteranddevel. To get around this, typeand the commit will disappear from
develsince it's already present inmaster.对于这种情况，我的一般工作流程是创建
master的bug-fix分支来修复问题。准备就绪后，将其合并回master，然后将master合并到develop。这假设您的错误修复在两个分支中需要更改的代码之间几乎是一对一的。如果是这种情况，您可以随时尝试
git merge -s ours master（请参阅 man-page) 到develop中，因此develop分支优先。我使用类似的流程来管理我正在从事的开源项目的错误修复版本。
master始终位于需要应用错误修复的位置之前，因此我从需要修复的标记创建一个分支，应用修复并发布，然后重新标记并将新标记合并到大师。由于版本号的原因，这会导致冲突，但可以使用上面的命令来避免。希望有帮助。
My general workflow for this situation is to create a
bug-fixbranch ofmasterthat fixes the problem. Once it's ready, merge that back intomasterthen mergemasterintodevelop.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) intodevelopso thedevelopbranch takes priority.I use a similar process for managing bug fix releases on an open-source project I'm working on.
masteris 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 intomaster. This causes a conflict because of the version numbers, but can be avoided with the command above.Hope that helps.
我通常遵循这个指南，它在大多数情况下非常适合并避免冲突和重大变化问题的市长。
如果您可以在
feature分支上工作，并仅在创建release分支之前将它们合并到development中（这意味着您实际上正在准备发布）。 ..此方法应该可以避免您遇到的大多数合并冲突。由于重大更改会发生在
功能破坏分支上，因此在该功能破坏分支合并到开发中时，您可能只会发生一次冲突。您也可以随时将development合并到release分支以保持更新。您还可以将所有的修补程序分支合并到开发中，并且冲突最少或根本没有冲突。
我之前在链接上分享的指南非常强调永远不要从
development合并到master或向后合并。始终通过release分支处理您的版本。I usually follow this guide which fits quite well in most cases and avoids mayor of issues with conflicts and big changes.
If you could work on
featurebranches and merge them indevelopmentonly prior to areleasebranch creation (meaning you are actually preparing a release)... this method should avoid most of the merge conflicts you experience.Since breaking changes would occur at a
feature-breakingbranch, you MAY only have conflicts once at the time thisfeature-breakingbranch gets merged into development. And you could as well mergedevelopmentinto thereleasebranch at any time to keep it updated.You will also be cool with merging into
developmentall thehotfix-branches you have with minimum or non conflicts at all.The guide I shared on the link before makes big emphasis on never merging from
developmenttomasteror backwards. Always handle your releases via areleasebranch.这一切都取决于您将如何使用 GIT 来管理您的代码、您的发布计划和您的版本。最佳实践是让
master分支保存您的生产级代码，让develop分支进行开发，让release分支从develop用于处理即将发布的版本，而hotfix分支是从master分支的，用于处理生产代码的紧急修复。因此，release和hotfix分支最终将合并回master和develop以确保两个分支进行更改，然后当develop分支出新的release时，这个新版本在master上合并没有问题。并且标记将始终位于master上。使用这种方法，
release和hotfix分支会被合并两次，并且在合并到develop时有时会出现冲突，如果有的话，这是不可避免的develop正在进行许多开发活动。缩短您的release或hotfix分支生命周期可能是缓解此问题的一种方法。如果发生冲突，请使用任何技术解决它，并确保不要更改已完成和测试的release或hotfix代码。This all depends on how you are going to use GIT to manage your code, your release plan, and your version. The best practise is to have
masterbranch to hold your production level code, havedevelopbranch to do your development, havereleasebranch branched out fromdevelopto handle your upcoming releases andhotfixbranch branched frommasterto handle urgent fixes for production code. So thereleaseandhotfixbranches will finally to be merged back to BOTHmasteranddevelopto make sure both branches have the changes and later on whendevelopbranches out newreleasethis new release has no problem to merge onmaster. And the tagging will be always onmaster.With this approach, the
releaseandhotfixbranches will be merged twice and the conflict is sometimes seen when merging todevelop, which is inevitable if there are many development activities going ondevelop. Shorten yourreleaseorhotfixbranch lifecycle could be a way to mitigate this problem. If conflict happens, solve it with whatever techniques and make sure don't change the completed and testedreleaseorhotfixcode.所有的答案都是臭的。
我个人的解决方案是中期发布。
每 3-7 天进行一次微发布，
就像您将其命名为 1.01、1.02 等等。客户的下一个版本将是 2.0
这些中期版本必须仅包含稳定的功能（因此尚未合并到 master 中）
这使您可以随着时间的推移保持 master 和开发的一致性，并轻松地进行 hotflix 并避免很多麻烦
All answers were smelly.
My personal solution is mid releases.
Once every 3-7 days you do a microrelease
Like you name it 1.01, 1.02 an so on. Next release on customer will be 2.0
Those mid release must include only features that are stable (and thus not merged into master yet)
This allow you to keep master and develop consistent over time and do hotflix with light heart and avoid lot of troubles
您描述了我们在过渡到 GIT 时遇到的一个问题。 Git-flow 的规则是您从修补程序分支合并以分别开发和掌握。
我们这样做时遇到的问题是，master 和 dev 都会分别获得 2 个不同的代码修复，因此当需要从开发合并到 master 时，master 会抱怨存在合并冲突，因为文件在两个分支中都发生了更改。您可能会认为它会发现它们在两者中是相同的更改，但是查看提交文本并意识到它们是同一件事的过程并不那么复杂。
我们还遇到了一个问题，即来自修补程序分支的代码更改没有进入开发分支。然后我们将在没有这种更改的情况下进行开发，当需要发布版本时，我们基本上是回滚，因为它不存在于开发分支中。当客户提醒您在下一个版本发布后代码不再工作时，请做好准备，进行大量咒骂和寻找代码更改！
因此，为了解决这些问题，我们将该规则更改为始终首先合并以开发，然后从该 PR 中挑选（或合并）以合并到 master。现在，两个分支都知道了这一更改，并且合并 ID 从一个分支到下一个分支都是相关的。
在规则更改之后，我们不再需要去寻找回滚的代码，并且因为该 PR 已经被合并和关联，所以在代码合并时不再出现问题。在发布时，当开发代码合并到主控时，不存在合并冲突。代码总是沿着分支层次结构的一个方向进行合并。
我希望这对某人有帮助！
谢谢！
You are describing a problem that we had when transitioning to GIT. The rule on Git-flow is that you merge from your hotfix branch to develop and master separately.
The problem we had when doing this was that both master and dev would get the 2 different code fixes separately, so when it came time to merge from develop to master, master would complain about have merge conflicts, because the files changed in both branches. You would think that it would figure out that they were the same changes in both, but the process isn't that sophisticated to looks at the commit text and realize it's the same thing.
We also had a problem with the code change from a hotfix branch not making it to the develop branch. Then we would develop without that change and when it was time to do a release, we were essentially rolling back because it didn't exist in the develop branch. Be prepared for lots of swearing and hunting to find that code change when the customer alerts you that it's not working any more after your next release!
So, to solve these issues we changed that rule to always merge to develop first, then cherry-pick (or merge) from that PR to merge into master. Now both branches are aware of the change and the merge ids are related from one branch to the next.
After this change to the rule, we no longer had to go hunt for rolled back code and because that PR has already been merged and related, no more merge problems when the code. At release time when the develop code is merged to master, there are no merge conflicts. The code is merged always going one direction through the branch hierarchy.
I hope this helps someone!
Thanks!