我为一家进行插件开发的公司工作。我们通常维护父应用程序的2个最新主要版本的插件。父应用程序的插件API的主要版本通常主要向后兼容，但总会有一些过时/弃用的部分以及几个新的API。因此，我们通常有两条发展线，随着时间的推移而不同。首先，当我们开始修复所有过时的调用时，分歧很小。随着时间的推移，随着我们开始使用新API，分歧会变得很大。合并这些分支可能会很麻烦，因为您必须确保不合并使用其他版本中不可用的API部分的代码。
我需要一些帮助来确定这种情况的最佳工作流程。我将在下面列出我的一些想法。父应用程序每年发布新的主要版本。因此，我们假设2013和2014年的插件API。
我们有2个长期运行的集中式分支，每个API版本1个（例如develop_2013，develop_2014）。我们针对develop_2013开发并一直合并到develop_2014。由于API 主要向后兼容，这通常可以正常工作。针对API的新部分的任何开发都在develop_2014中完成，并且不会合并回来。
我对这种方法持谨慎态度，认为git并不是为了维持长期运行的分支。
我们现在的情况是，我们为父应用程序的每个主要版本都有一个存储库（例如plugin_2013和plugin_2014）。我们现在必须通过合并请求合并每个存储库之间的代码，或者将一个作为远程添加到另一个存储库。我们或许可以选择改变。
我对这种方法持谨慎态度，因为它会给流程带来更多开销。
如果可能，我宁愿保留1个存储库中包含的特定插件的所有开发。我只是担心有两个分支随着时间的推移会变得越来越分散的麻烦。
答案 0 :(得分：0)
我更喜欢使用发布分支和修补程序分支，也许您已经知道git flow https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow。 对我来说，这是保持代码控制的最佳方式。 另一方面，在你的情况下，我用来隔离api相关的调用，以避免api更改对开发过多影响。
答案 1 :(得分：0)
所以我最初发布的这篇文章是因为我缺乏git的经验。在同一个仓库中维护2个长期运行的分支机构对我们来说很好。在我发布问题时我并不完全理解的真正潜在问题是，我并不想每次合并时都必须解决相同的合并冲突。我不确定git是否可以直接处理它，但是肯定可以做到这一点。