在git中，如何对十二个库进行版本控制

我们正在做项目，但是我们在项目之间重用了很多代码，并且有很多包含我们共同代码的库。在实施新项目时，我们发现了更多方法来分解通用代码并将其放入库中。这些库相互依赖，而项目则取决于这些库。每个项目以及该项目中使用的所有库都需要使用它们所引用的所有库的相同版本。如果我们发布某个软件，则我们将不得不修复错误，并可能添加许多年甚至数十年的新功能。我们有大约十二个库，更改通常跨越两个以上，并且几个团队并行处理多个项目，并同时对所有这些库进行更改。

我们最近已切换到git并为每个库和每个项目设置存储库。我们使用存储作为公共存储库，在功能分支上进行新工作，然后发出拉取请求并仅在审阅后合并它们。

我们必须在项目中处理的许多问题都要求我们在多个库和项目的特定代码之间进行更改。这些通常包括库接口的更改，其中一些不兼容。（如果您认为这听起来有些可疑：我们与硬件进行交互，并将特定的硬件隐藏在通用接口之后。几乎每次我们集成其他供应商的硬件时，都会遇到我们当前的接口无法预期的情况，因此必须对其进行完善。）例如，假设一个项目P1使用的库L1，L2和L3。L1还采用了L2和L3，并L2使用L3为好。依赖关系图如下所示：

   <-------L1<--+
P1 <----+  ^    |
   <-+  |  |    |
     |  +--L2   |
     |     ^    |
     |     |    |
     +-----L3---+

现在，想象一下此项目的功能需要更改，P1并L3更改的界面L3。现在添加项目P2并添加P3到组合中，它们也引用这些库。我们不能将它们全部切换到新界面，运行所有测试并部署新软件。那有什么选择呢？

1. 在中实现新接口 L3
2. 提出请求L3并等待审查
3. 合并变更
4. 创建一个新版本 L3
5. P1通过参考L3的新版本开始使用该功能，然后在其P1功能分支上实现该功能
6. 提出拉取请求，对此进行审核并合并

（我只注意到我忘了切换L1，并L2到新版本，而我甚至不知道在哪里要坚持这一点，因为这将需要同时做同P1...）

这是一个繁琐，容易出错的过程，并且实施此功能的过程非常漫长，它需要进行独立审核（这使得审核变得更加困难），根本无法扩展，并且有可能使我们停业在过程中陷入困境，我们永远都做不完。

但是，如何使用分支和标记来创建一个流程，使我们能够在新项目中实现新功能而又没有太多开销？

有点在这里说清楚，但也许值得一提。

通常，git repos是针对每个库/项目量身定制的，因为它们往往是独立的。您可以更新项目，而不必关心其余的事情。取决于它的其他项目将在他们认为合适的情况下简单地更新其lib。

但是，您的案例似乎高度依赖于相关组件，因此一项功能通常会影响其中的许多组件。整个必须打包成捆。由于实现功能/更改/错误通常需要一次适应许多不同的库/项目，因此将它们全部放在同一个存储库中可能是有意义的。

有很强的优势/缺点。

优点：

• 可跟踪性：该分支显示了每个项目/库中与此功能/错误相关的所有更改。
• 捆绑：只需选择一个标签，即可正确使用所有来源。

缺点：

• 合并：...单个项目有时已经很困难。由不同的团队在共享分支机构中工作，请做好准备以备影响。
• 危险的“哎呀”因素：如果一名员工因犯了一些错误而弄乱了存储库，则可能会影响所有项目和团队。

由您决定价格是否值得。

编辑：

它将像这样工作：

• 功能X必须实现
• 创建分支 feature_x
• 所有涉及此分支的开发人员都可以在该分支上并行工作，可能在与他们的项目/ lib相关的专用目录中
• 一旦结束，请进行检查，测试，包装，无论如何
• 将其合并回主服务器中……这可能是困难的部分，因为与此同时feature_y，它feature_z可能也已添加。它成为“跨团队”合并。这就是为什么它是一个严重的缺点。

仅作记录：我认为在大多数情况下这是一个坏主意，应谨慎进行，因为合并缺陷通常比通过依赖项管理/适当的功能跟踪获得的缺陷要高。

您正在寻找的解决方案是与git子模块配合使用的依赖项管理工具

工具如：

• 马文
• 蚂蚁
• 作曲家

您可以使用那些工具来定义项目的依赖关系。

您可以要求子模块的版本至少为> 2.xx，或者表示一系列兼容的版本= 2.2。*或小于特定版本<2.2.3。

每当您发布其中一个软件包的新版本时，都可以使用版本号对其进行标记，这样就可以将特定版本的代码引入所有其他项目中。

子模块

您应该尝试在一个注释中建议git子模块。

当项目P1是指三个子模块L1，L2并且L3，它实际存储在所有三个仓库，以特定的提交参考：这些都是工作的每个库的版本该项目。

因此，多个项目可以与多个子模块一起工作：当项目使用新版本时，P1可能引用旧版本的库。L1P2

交付新版本的会发生什么L3？

• 在中实现新接口 L3
• 提交，测试，发出拉取请求，查看，合并...（您无法避免）
• 确保L2与L3，提交，...一起工作
• 确保L1与新的L2...一起使用
• 确保P1适用于所有库的新版本：
  • 里面P1的本地工作副本L1，L2并且L3，fetche你有兴趣的变化。
  • 提交更改，git add L1 L2 L3以提交对模块的新引用
  • 提取请求P1，测试，审查，提取请求，合并...

方法

这是一个繁琐，容易出错的过程，并且实施此功能的过程非常漫长，它需要进行独立审核（这使得审核变得更加困难），根本无法扩展，并且有可能使我们停业在过程中陷入困境，我们永远都做不完。

是的，它需要独立审核，因为您需要更改：

• 图书馆
• 依赖它的库
• 依赖多个库的项目

你会因为丢人而倒闭吗？（实际上可能不是）。如果是，那么您需要执行测试并检查更改。

使用适当的git工具（甚至gitk），您可以轻松查看每个项目使用的库版本，并可以根据需要独立更新它们。子模块非常适合您的情况，并且不会减慢您的处理速度。

也许您可以找到一种自动执行此过程的一部分的方法，但是上述大多数步骤都需要人脑。缩短时间的最有效方法是确保您的库和项目易于开发。如果您的代码库可以很好地处理新要求，那么代码审查将变得更加简单，并且只需很少的时间。

（编辑） 可能对您有所帮助的另一件事是将相关的代码审阅分组。您提交所有更改，并等到将这些更改传播到使用它们的所有库和项目之后，再对拉取请求进行汇总（或处理它们）。您最终需要对整个依赖项链进行更大的审查。如果每个本地更改很小，这也许可以帮助您节省时间。

所以我了解的是，对于P1，您想更改L3接口，但是您希望其他依赖L3接口的P2和P3立即更改。这是向后兼容的典型情况。关于保留向后兼容性，有一篇不错的文章

有几种方法可以解决此问题：

• 您每次都必须创建新接口，以扩展旧接口。

要么

• 如果要在一段时间后停用旧界面，则可以使用多种版本的界面，并且一旦所有相关项目移动后，您将删除旧界面。

如果我正确解决了您的问题：

• 您有4个相互关联的模块，P1和L1至L3
• 您需要对P1进行更改，这最终会影响L1至L3
• 如果必须同时更改所有四个，则视为过程失败
• 如果必须将它们全部更改为1，则视为过程失败。
• 如果您必须提前确定必须进行更改的块，则将其视为过程失败。

因此，目标是您可以一次完成P1和L1，然后一个月后再进行一次L2和L3。

在Java世界中，这很简单，也许是默认的工作方式：

• 一切都在一个存储库中进行，没有分支的相关使用
• 模块根据版本号由maven编译+链接在一起，而不是全部都在同一目录树中。

因此，您可以将L3本地代码存储在本地磁盘上，如果该代码是针对磁盘上其他目录中的P1副本进行编译的，则该代码不会编译；幸运的是它没有这样做。Java可以直接执行此操作，因为编译/链接故事是针对已编译的jar文件而不是源代码。

对于C / C ++世界，我不知道针对此问题已存在的广泛使用的解决方案，并且我想您几乎不想切换语言。但是很容易将与做同样事情的make文件一起黑客入侵：

• 已安装的库+带有已知版本号的已知目录的头
• 更改了每个模块到目录的相应版本号的编译器路径

您甚至可以在maven中使用C / C ++支持，尽管如果您这样做，大多数C开发人员都会奇怪地看着您...

有一个简单的解决方案：在整个存储库中剪切发行版分支，将所有修补程序合并到所有活跃发布的发行版中（很明显，很容易在git中实现）。

随着时间的推移，随着项目的发展，所有替代方案都会造成可怕的混乱。