将 git 用于具有 2 行开发的项目答案

【问题标题】：Using git for a project with 2 lines of development将 git 用于具有 2 行开发的项目
【发布时间】：2015-01-20 21:09:01
【问题描述】：

我在一家从事插件开发的公司工作。我们通常为父应用程序的 2 个最新主要版本维护我们的插件。父应用程序插件 API 的主要版本通常大多是向后兼容的，但总是有一些过时/弃用的部分以及几个新的 API。因此，随着时间的推移，我们通常有两条发展路线。起初，分歧很小，因为我们首先修复了所有过时的调用。随着时间的推移，随着我们开始使用新的 API，分歧可能会变得更大。在这些分支之间进行合并可能会很痛苦，因为您必须确保没有合并使用其他版本中不可用的 API 部分的代码。

我需要一些帮助来确定适合这种情况的最佳工作流程。我将在下面列出我的一些想法。父应用程序每年发布新的主要版本。因此，让我们假设 2013 年和 2014 年的插件 API。

1。为每个 API 版本维护一个分支

我们有 2 个长期运行的集中式分支，每个版本的 API 1 个（例如，develop_2013、develop_2014）。我们针对develop_2013 进行开发，并始终合并到develop_2014。由于 API大部分向后兼容，这通常可以正常工作。针对 API 新部分的任何开发都在 develop_2014 中完成，不会合并回来。

我对这种方法持谨慎态度，因为 git 并不真正适合维护长期运行的分歧分支。

2。每个 API 版本的分叉

我们现在的情况是，我们为父应用程序的每个主要版本（例如 plugin_2013 和 plugin_2014）都有一个存储库。我们现在必须通过合并请求或通过将一个作为远程添加到另一个来合并每个存储库之间的代码。我们也许可以挑选变化。

我对这种方法持谨慎态度，因为它会在流程中引入更多开销。

如果可能，我希望将特定插件的所有开发都包含在 1 个存储库中。我只是担心有 2 个分支会随着时间的推移变得越来越不同。

【问题讨论】：

出于好奇，你为什么说“git 并不是真正适合维护长期运行的分歧分支。”？ Github 使用在同一存储库中拥有完全不相关的分支的能力来驱动 github 页面（gh-pages）。
您是否标记了两个 API 分支的发布？如果你是，并且你在一个存储库中，当 2015 API 出现时，你可以删除 2013 分支（最后一个标签将确保历史仍然可以访问），然后从 2014 分支创建 2015 分支.保留已弃用 API 分支的历史记录有多重要？
@Charlie 在我看来，git 分支模型的意图是，每条开发线最终都注定要汇回一条开发线。在我的情况下，我的 2 个分支只会随着时间的推移而更加分歧。如果我要在合并期间放弃特定的更改，git 会知道未来的合并吗？还是每次我进行合并时都必须拒绝这些更改？
@Charlie 这就是目的。我更愿意标记 2013 年的最终版本并删除分支。然后，我将从 2014 年分支到 2015 年，并对过时的 API 调用进行必要的更新。我们一直在尝试使用 git flow，但是当我们现在必须保持 2 条活跃的开发线时，我不确定它是如何真正起作用的。
那就去做吧 :) Git flow 和所有其他分支模型真的并不意味着蹲下，除非你有一个同意遵循它们的团队。你没有理由不能定义一个适合你项目需求的模型，只要它在技术上是可行的，而且 git 非常灵活，有各种各样的工具和技巧，比如rerere 等等。

标签： git git-branch git-fork

【解决方案1】：

我更喜欢使用发布分支和修补程序分支，也许你已经知道 git flow https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow。对我来说，这是控制代码的最佳方式。另一方面，在您的情况下，我使用隔离 api 相关调用以避免 api 更改对开发产生太大影响。

【讨论】：

【解决方案2】：

所以我意识到我最初的帖子是由于我缺乏 git 经验。在同一个 repo 中维护 2 个长期运行的分支对我们来说很好。我在发布问题时不太了解的真正潜在问题是，我不想每次合并时都必须解决相同的合并冲突。我不确定 git 是否开箱即用，但 rerere 肯定能解决问题。

【讨论】：