我正在为另一个开源软件构建一个开源客户端。第三方软件使用1.0、1.1、2.0、2.1等标签对其版本进行版本版本。这些版本都合并回master，其软件的任何补丁都会增加版本控制，因此目前没有修补多个主要版本的概念。
在这些不断变化的版本中，这是其代码中的一些显着差异，这些差异代表了我在客户端中需要的代码的相当大的差异。因此，支持 1.0 的客户端可能会与支持 1.1 版的客户端存在一些不兼容的差异，尽管它们将共享大部分代码库。当我发现错误/改进时，我还需要修补客户端的每个版本。有时，该修补程序可能会影响客户端的每个版本，有时可能仅影响 1 个版本。因此，尽管我可能正在开发客户端的 2.1 版(对应于第三方软件的 2.1 版)，但我可能不得不返回并在原始 1.1 客户端版本上发布 1.1.1 补丁(希望一切都有意义)。
我正在尝试找出与Git一起使用的策略(我在Visual Studio和GitHub工作)来支持这一点。现在，我倾向于从 master 为每个版本的软件创建一个分支，更新代码以与新版本兼容，然后将其合并回 master，并用特定的补丁版本号标记每个分支中的每个提交。这应该允许我签出特定的分支版本以更新、提交和重新打包以进行部署。我不认为它处理更新某些内容，尽管这在每个分支中仍然很常见，所以我需要在每个分支中执行更新(并且显然为每个分支提交新的标签版本)。
有没有更好的方法来完成我想要完成的事情？
如果(a) 可以预测代码的哪些部分会因版本而异，或者 (b) 您可以以一种允许特定于版本的项目中的版本覆盖核心项目行为的任何给定部分的方式构建代码，则可以将其拆分为"核心"项目和"特定于版本"的项目。 这不是一个完美的解决方案 - 我不确定是否有 - 但它可以缓解您描述的一些问题。