代码之家 › 专栏 › 技术社区 › T Lytle

如何处理多个Git存储库

versioning bitbucket git

T Lytle · 技术社区 · 6 年前

我在两个不同的独立系统上工作,我们将代码存储在bitback(git)上。这两个不同的系统位于BitBucket上的两个不同的存储库中。我们就叫他们“system1”和“system2”。每个存储库都遵循Gitflow的主/开发/发布分支方案。

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

“system1”和“system2”存储库都有一个构建脚本。构建脚本期望每个存储库都在同一目录级别克隆。例如,如下所示:

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

生成脚本使用 git describe 标记每个构建。它使用 Git描述 在每个存储库中创建一个构建。因此,作为一个例子,构建信息 system1 如下所示:

SYSTEM1: 10.1.1
SHARED_LIBRARY: 10.1.1
NETWORKING: 10.1.1

所有这些软件都捆绑在一起并安装到目标机器上,带有System1标签。

我的问题是如果 networking 那么,这不会反映在的内部版本号中 系统1 .例如,假设对 网络 .现在运行生成脚本如下所示:

SYSTEM1: 10.1.1
SHARED_LIBRARY: 10.1.1
NETWORKING: 10.1.1-1

安装后,它看起来仍然像10.1.1版,即使它不是(因为网络已经改变)。

本质上,我需要更改我的方案,以便某些其他存储库中的更改反映在 Git描述 输出输入 系统1 .

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

1 回复 | 直到 6 年前

Will Cain 6 年前

首先,如果依赖项(网络)版本已更新但依赖项(系统1)版本未更新,那么检查版本更新并失败的构建时测试如何?然后您至少可以自动检测并手动解决过时的依赖版本。在您的示例中,网络是递增的,但System1不是,在这种状态下构建System1时,测试将失败,因此构建也将失败。根据您的需要,实现测试可能与检查是否存在 -<commits> (例如 -1 )任何依赖项中的后缀。或者像检查工件存储库中最新构建的工件版本一样复杂。精确的逻辑非常依赖于您的环境。

然后,作为可选的下一步,您可以移动到完全自动化版本的增加。不要在bitback中手动标记,而是让构建系统(或者甚至只是手动启动,但其他情况下是自动升级脚本)增加版本,而不是手动设置它们。这个自动化的解决方案可以做一些事情,比如将版本增量从依赖(网络)自动级联到依赖(系统1)。您可能会使用这类系统自动进行标记,例如在成功构建时。我已经看到这种方法的部分成功使用。

还有一种解决方案可能会更多地利用Git,但是自动化构建系统中的一些版本检查或增量的一个好处是,它可能会使您的管道更少地依赖于您的实现技术选择(例如Git、NPM、特定语言等)。