我有一个关于git分支实践的简单问题：
假设有master和develop个分支。所有功能开发任务都在相应的功能分支上进行，并以develop分支为目标。 （功能分支从develop分支出来）
我有发布1.0.0版应用程序的任务，与此同时，我还有发布1.1.0版应用程序的任务。
一般来说，任务应该以{{1}}分支为目标，但是我不想发布包含1.1.0功能的1.0.0，因此，我不能将所有任务都合并到{ {1}}分支。
我能想到的解决方案是为1.1.0提供一个develop分支（从develop分支），将1.1.0的任务合并到该temporary分支中。等待直到创建了1.0.0的发行候选分支，然后将该develop分支合并到temporary以便将来发行1.1.0。
比我想出的更好吗？
答案 0 :(得分：1)
一般来说，任务应该针对开发分支
主要是对于流行的git-flow工作流程而言。对此没有“应该”，git本身对您的使用方式也没有意见。
git-flow仅在您只有一个“下一个”版本时有效，如果您非常了解下一版本的内容，并且通常不希望撤消develop中的更改，科。例如，在我当前的主要项目中，这三个假设是错误。因此，我们不使用git-flow。
我能想到的解决方案是拥有一个临时分支（从开发分支出来）
为什么首先要从develop分支出来？您可以改为使用master（含义为“当前版本”）。如果您所有的分支机构都来自master，并且您摆脱了develop，并且拥有临时的远期分支机构，这些分支机构经常从头开始重建（重置为master，合并所有相关功能），在继续并行开发所有新功能的同时，以多个未来版本为目标是没有问题的。有一个名为branch-per-feature的工作流程对此非常有用。
答案 1 :(得分：0)
该问题的答案将因工作流程而异（并且随团队偏好和项目性质而异），因此，该问题倾向于基于观点或过于宽泛……但我想一些普遍的想法是：
最简单的方法是最小化为多个版本开发功能时的重叠时间。从优先级和努力的角度来看，这通常还是有道理的。
例如，流行的gitflow工作流程或多或少地假设即将发布的版本的所有开放feature分支都是（至少可能）。关闭版本x的功能集后，即可创建版本x的发行分支。只有与发行版相关的工作和较小的错误修正才可以在发行分支上进行（最终会合并回develop，这样的修正不会丢失）。并且是在创建功能x版本分支时，所有打开的功能都将成为“版本x+1功能”，并且您打开了x+1版本中已保留的所有新功能。< / p>
（一个相关的观点：灵活选择发布哪些功能是很有用的，以便您可以随时准备释放具有任何价值的发布。这在某种程度上与敏捷思维有关。）< / p>
但是，如果您发现积极开发两个版本是您项目的一种方式，则需要做一些不同的事情。我会完全放弃创建develop分支的想法，因为随之而来的分支名称杂乱无章。
因此，发行版开发分支（例如dev-1.0.0）可以代替develop。您将在先前的发行开发分支中创建一个发行开发分支，但是此后，您必须定期将先前发行开发分支中的更改合并到当前发行开发分支中。由于这是一个共享/长期存在的分支，因此您不希望通过rebase来执行此操作，这意味着可能需要定期合并提交。
还有其他方法，就像我说的那样，一旦您摆脱了经过文件记录和时间验证的方法，它就会迅速进入观点领域。