我们几乎已经找到了一个分支模型，我们有一个代表生产代码的master分支和一个代表未来版本的release-x.x分支。
但是，有一些情况我们不确定如何有效解决：
实时错误修复与当前版本无关
新的feature是release-2.0的分支，并完成了对模块A的重写。
新的feature已完成并在release-2.0合并。
在master上找到并修复了当前实时模块A中的错误。
此时我们认为有两种可能的情况：
我们在release-2.0上重新master以修复错误并修复冲突（丢弃现在无关的错误修复代码）。最后，我们会在发布准备就绪时在release-2.0中合并master。
我们只挑选与release-2.0版本相关的错误修复程序，当发布版准备就绪时，我们会使用master历史记录覆盖整个release-2.0历史记录
解决方案＃1迫使我们解决与我们知道不需要的提交的合并冲突，但解决方案＃2迫使我们擦除整个master分支并将其替换为release-2.0分支的历史记录每一个版本。这引入了一个轻微的机会，可能会丢失我们忘记在release-2.0上挑选的错误修复，并且还可能会破坏在发布前master分支的持续错误修复。
功能不会在事后发布
feature上创建了一个新的release-2.0个rebase，并将其release-2.0与--no-ff合并。feature上修复它们并重做上述合并过程。release-2.0进行这些更改，并且必须等到{{1 }}。处理这种情况的正确方法是什么？我们是否应该使用“恢复功能X - 推回到3.0”等消息还原与release-3.0中所执行功能相关的所有提交，然后再将release-2.0合并到feature？< / p>
答案 0 :(得分：0)
首先，如果您在release-2.0和master分支中更改了模块A，并且您希望将master上的模块A的更改应用到您的release-2.0分支。
除了您列出的解决方案1和解决方案2之外，还有另一种方法，您只能将模块A的更改从master应用到release-2.0。这是直接从master检出相关文件到release-2.0，然后提交更改。详细步骤如下：
git checkout release-2.0
git checkout master /path/to/moduleA
# Such as git checkout master moduleA/*
# Now module A is what you changed in master
git commit
第二，对于大多数情况，如果您使用版本格式为x.y（major.minor），x（主要）代表所需的主要/重大更改客户和y（次要）意味着我们修复错误或客户在审核您所做的工作时几乎不需要进行任何更改。
因此，如果您的客户在审核2.0版本时发出重大更改请求，则可以将项目开发为3.0版。完成工作后，您的客户将审查3.0的版本。如果他们报告版本3.0的错误或微小更改，您可以将版本更改为3.1（将release-3.0分支重命名为release-3.1或在完成更改后添加标记3.1。
除了之外，您可以参考another different branching module：适用于develop分支 - ＆gt;完成工作时 - ＆gt;将develop合并到release分支 - ＆gt;在release分支获得批准/审核后 - >将release合并到master分支 - ＆gt;记录标签中的发布版本。
答案 1 :(得分：0)
我建议使用标签而不是分支来表示生产中的内容。这样你就可以简单地签出一个新的修补程序分支并修复你的bug，然后直接部署这个提交并将其标记为当前的生产代码，如果你知道一切都将改变下一个版本，则无需将其合并。
* 54c82e0 - (HEAD -> master) Commit6
* bb6db8e - Commit5
* 5156c9f - Commit4
| * 630a150 - (tag: v1.1) Hotfix commit
|/
* db5c984 - (tag: v1.0) Commit3
* 00c6c5c - Commit2
* 715412a - Commit1
您将使用已计划的分支模型，但是master将成为您的＆＃34; trunk＆＃34;，其中所有工作都合并到，而当前生产代码将始终具有标记，如果需要修补程序，可以查看。
我会谨慎选择一个经过验证的＆＃34;盲目地像GitFlow这样的分支模型，所以我认为你走在正确的轨道上，试图找出适合你的需求。欲了解更多信息，请参阅：