两个主要分支的Git工作流？ 我需要为以下情况定义Git工作流： 目前有一个版本正在生产中（我们称之为v1.x） 还有一个新版本（v2.x）将在未来某个时候取代当前版本 它们都共享很多功能（到目前为止，大约80%的代码是相同的） 两个版本都在积极开发中： 对于v1.x和v2.x 20%专门用于v1.x，20%仅用于v2.x 两个版本都在测试中（产品用户/测试人员） 有时需要prod（v1.x）的修补程序 没有高优先级的bug会像正常任务一样被处理 每1-2个月发布一个新的产品版本（例如v1.1->v1.2） 我们目前的做法是： 将master视为v1.x 为发行版创建新分支（v1.1，v1.1，…） 在master上开发通用代码，并将其合并到v2.x 仅在一个分支上为v1.x/v2.x开发代码，不要将这些更改合并到另一个分支 我做了一些研究，发现： -我不知道如何将其应用于我的案例（两个主要分支共享大量代码） -我在一个类似的SO主题中发现了它，但是，我仍然不知道如何在我的案例中使用它 总而言之：

您能告诉我所描述的案例可能的Git工作流程是什么吗？
分支应该是什么样子？

---

我应该合并什么？如何合并（cherry pick？）只提交我想要的代码，而不合并不需要的代码？

关于常见代码。这是您可以在应用程序中作为库共享的东西，还是以与v1.x和v2.x类似的方式进行解耦？是否有可能拥有自己的共享代码存储库，或者它应该与具有不同版本的同一存储库共存？我在过去也遇到过同样的问题，我们正在进行

v1

项目，我们在未来的

v2

版本上进行了巨大的重构。我们使用的是“从微观到宏观-GIT分支模型和工作流程”，几乎没有什么变化：-在v2成为正式生产版本之前，我们将其视为一种功能（即，不是

主版本

）-每次我们对

v1

进行错误修复或新功能时，我们也会将其合并到

v2

-当

v2

准备就绪时，您只需移动“master”对于

v2

的负责人，我已经成功地使用了

git merge base release/v1 release/v2

来确定将合并到两个分支中的新开发的理想基础。@T.Nylund将很难将通用代码提取到库中-这是一个前端应用程序，您永远不知道设计师将要更改什么;) 然而，对于代码的一些小部分，这是可能的。我会检查这个方法，谢谢你的建议@NatanBraslavski感谢您提供的分支模型，我以前没有看过这篇文章。我很高兴这样一个模型在您的项目中发挥了作用，它看起来也可以在我的项目中发挥作用：）