在git中，如何对十二个库进行版本控制
我们正在做项目，但是我们在项目之间重用了很多代码，并且有很多包含我们共同代码的库。在实施新项目时，我们发现了更多方法来分解通用代码并将其放入库中。这些库相互依赖，而项目则取决于这些库。每个项目以及该项目中使用的所有库都需要使用它们所引用的所有库的相同版本。如果我们发布某个软件，则我们将不得不修复错误，并可能添加许多年甚至数十年的新功能。我们有大约十二个库，更改通常跨越两个以上，并且几个团队并行处理多个项目，并同时对所有这些库进行更改。 我们最近已切换到git并为每个库和每个项目设置存储库。我们使用存储作为公共存储库，在功能分支上进行新工作，然后发出拉取请求并仅在审阅后合并它们。 我们必须在项目中处理的许多问题都要求我们在多个库和项目的特定代码之间进行更改。这些通常包括库接口的更改，其中一些不兼容。（如果您认为这听起来有些可疑：我们与硬件进行交互，并将特定的硬件隐藏在通用接口之后。几乎每次我们集成其他供应商的硬件时，都会遇到我们当前的接口无法预期的情况，因此必须对其进行完善。）例如，假设一个项目P1使用的库L1，L2和L3。L1还采用了L2和L3，并L2使用L3为好。依赖关系图如下所示： <-------L1<--+ P1 <----+ ^ | <-+ | | | | +--L2 | | ^ | | | | +-----L3---+ 现在，想象一下此项目的功能需要更改，P1并L3更改的界面L3。现在添加项目P2并添加P3到组合中，它们也引用这些库。我们不能将它们全部切换到新界面，运行所有测试并部署新软件。那有什么选择呢？ 在中实现新接口 L3 提出请求L3并等待审查 合并变更 创建一个新版本 L3 P1通过参考L3的新版本开始使用该功能，然后在其P1功能分支上实现该功能 提出拉取请求，对此进行审核并合并 （我只注意到我忘了切换L1，并L2到新版本，而我甚至不知道在哪里要坚持这一点，因为这将需要同时做同P1...） 这是一个繁琐，容易出错的过程，并且实施此功能的过程非常漫长，它需要进行独立审核（这使得审核变得更加困难），根本无法扩展，并且有可能使我们停业在过程中陷入困境，我们永远都做不完。 但是，如何使用分支和标记来创建一个流程，使我们能够在新项目中实现新功能而又没有太多开销？