如何处理多个 Git 存储库答案

【问题标题】：How to Handle Multiple Git Repositories如何处理多个 Git 存储库
【发布时间】：2018-07-11 06:02:02
【问题描述】：

我在两个不同的独立系统上工作，我们将代码存储在 BitBucket (Git) 上。这两个不同的系统位于 BitBucket 上的两个不同存储库中。让我们称它们为“system1”和“system2”。每个存储库都遵循 GitFlow 并带有一个 master/develop/release 分支方案。

我们还有一个单独的存储库，其中包含一个供“system1”和“system2”使用的共享库。还有另一个存储库，其中包含“system1”和“system2”也使用的所有网络相关软件。

“system1”和“system2”存储库各有一个构建脚本。构建脚本期望每个存储库都在同一目录级别克隆。所以，例如，像这样：

~/system1
~/system2
~/shared_library
~/networking

构建脚本使用git describe 标记每个构建。它使用每个存储库中git describe 的输出来创建构建。因此，作为示例，system1 的构建信息如下所示：

SYSTEM1: 10.1.1
SHARED_LIBRARY: 10.1.1
NETWORKING: 10.1.1

所有这些软件都捆绑并安装到带有 SYSTEM1 标签的目标机器上。

我遇到的问题是，如果networking 有变化，那么这不会反映在system1 的内部版本号中。例如，假设对networking 进行了一次提交。现在运行构建脚本如下所示：

SYSTEM1: 10.1.1
SHARED_LIBRARY: 10.1.1
NETWORKING: 10.1.1-1

安装后，它看起来仍然像 10.1.1 版本，即使它不是（因为网络已经改变）。

基本上，我需要更改我的方案，以便某些其他存储库中的更改反映在system1 的git describe 输出中。

我不确定如何做到这一点。

【问题讨论】：

标签： git bitbucket versioning

【解决方案1】：

首先，如果依赖（网络）版本更新但依赖（system1）版本没有更新，则检查版本更新并失败的构建时测试如何？然后，您至少可以自动检测并手动解决过时的依赖版本。在您的示例中，网络增加但 system1 没有增加，当在这种状态下构建 system1 时，测试将失败，因此构建也会失败。根据您的需要，实现测试可能就像检查任何依赖项中是否存在任何-<commits>（例如-1）后缀一样简单。或者像检查您的工件存储库以获取最新构建的工件版本一样复杂。精确的逻辑很大程度上取决于您的环境。

然后作为可选的下一步，您可以完全自动地增加版本。与其在 BitBucket 中手动标记，不如让构建系统（或者甚至只是手动启动但自动升级的脚本）增加版本，而不是手动设置它们。这种自动化解决方案可以执行诸如自动将版本增量从依赖项（网络）级联到依赖项（system1）之类的事情。您可以潜在地使用这种相同类型的系统来自动进行标记，例如在成功的构建上。我已经看到成功使用了这种方法的一部分。

可能还有一个解决方案可以更多地利用 git，但是在构建系统中自动执行某些版本检查或增量的一个好处是，它可以潜在地使您的管道更少依赖于您的实现技术选择（例如 git、 npm、特定语言等）。

【讨论】：

我的理解是，当您使用git describe 时，它会自动附加自最近注释标记以来的提交次数。您的建议是完全取消这一点，只需在脚本中手动跟踪我的内部版本号。我的理解正确吗？
对于您的第一句话，networking 可能包含新提交，但 system1 可能不包含任何新提交。从本质上讲，system1 的新版本仅包含网络更新。 system1 中没有新的提交，因此 git 仅将其视为 10.1.1。
谢谢，我想我可以更新我的答案以纳入其中的一些细节并解决您的一些问题...问您一个问题...您今天在哪里/如何指定版本？（是什么创建了版本标签？）例如，我熟悉在 npm package.json 或 maven pom.xml 等文件中声明的版本。
在上述 cmets 中对您的问题的简短回答是，不，我无意建议您更改如何您的版本或生成标签。我的回答主要是添加到您的系统中，即添加测试（执行）和自动化。
哦，还有一个问题，system1 的构建是如何触发的？如果您还没有这个，我认为您可能需要考虑从更改其依赖项（网络等）触发 system1 构建。这在 Jenkins 和大多数 CI 系统中很简单。