在 master 远远超出该版本之后，git flow 如何处理修补程序？
Scenario
- 1.0 的工作在开发中执行，在releases/v1.0发布分支上稳定，并在快进合并中推送到master，标签v1.0指向master的尖端和稳定分支的尖端
- 版本 1.1 - 3.2 的发生方式大致相同。
-
我们需要修复 1.0 中的错误
- 来自 v1.0 标签的分支
- 执行修复
- 合并到哪里？
Master 是遥远的未来，任何合并都不会快进，并且为了好玩，可以说会发生冲突。
我会合并到发布稳定分支并创建新标签吗？这是后续修补程序将使用的起点吗？
nvie 的部分修补程序分支 http://nvie.com/posts/a-successful-git-branching-model/#hotfix-branches解释说这些是……
...非常类似于发布分支，因为它们也旨在为新的生产版本做准备，尽管是计划外的。
因此，它们应该在最新的基础上完成master版本，当当前内容在develop还没有准备好正常release cycle.
您在这里想要修补旧版本的是以下概念：support分支，在很久很久以前，在最初的 git flow 发布之后就讨论过这个问题，但据我所知，从未被完整记录过。
The gitflow-avh工具似乎确实很好地支持它们，因此您可能想在测试存储库中探索它：
- 参考：git flow 支持 · petervanderdoes/gitflow-avh Wiki https://github.com/petervanderdoes/gitflow-avh/wiki/Reference:-git-flow-support
我确实找到了一些带有“信息”的帖子support分支，但对他们的解释不太满意……鉴于缺乏有关它们的信息，无论如何我都会链接它们：
- 入门 – Git-Flow |一些想法、想法和乐趣！ https://yakiloo.com/getting-started-git-flow/
- GitFlow 示例 - GitVersion http://gitversion.readthedocs.io/en/stable/git-branching-strategies/gitflow-examples/#support-branches
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
