您使用什么工具或技术在存储库之间同步配置？

如何解决您使用什么工具或技术在存储库之间同步配置？

我们有几个基本存储库，可用于快速构建新项目。其中包括诸如以下内容的基本存储库：

• TypeScript +节点库
• TypeScript +节点微服务/工作者
• 角度应用程序
• gRPC存根/ protobuf库
• 等

基础存储库包含启动新项目所需的所有配置和文件夹结构，类似于ng new，create-react-app，yeoman生成器等。其中包括CI配置，测试配置，带有脚本和开发依赖项的linting config，tsconfig，package.json，用于设置的VSCode文件，扩展建议，启动配置等。基本上，存储库包含您需要在这些类似的存储库之间共享的所有内容，除了代码

有一些工具可以在存储库之间共享代码，例如bit，或者您也可以发布库以共享代码，我们已广泛使用了这些工具。但是，我还没有找到在许多存储库之间共享配置文件的 great 方法。我们可以简单地从基本存储库克隆或编写我们自己的生成器，但是问题是保持配置同步。例如，如果我们更改CI配置，那么我就不必记住哪个50个存储库基于还需要更改的存储库。

我们不能成为这里唯一拥有超过100个回购协议的公司，而且随着我们分裂为越来越多的分布式服务和库，增长没有尽头。我们可以采用monorepository模式，但是仍然不能改变以下事实，即monorepo中的每个项目仍然需要自己的配置，该配置必须在所有项目中保持同步。

问题是，我缺少什么工具或技术可以处理多个不同存储库之间的同步配置？

解决方法

这是我们当前的操作方式：

• 创建一个新文件夹并在其中运行git init
• 为您的存储库添加远程（origin）
• 将辅助遥控器（base）添加到基本存储库
• 将推送网址设置为无效的网址，这样您就无法推送到基础存储库（例如git remote set-url --push base NOPUSHALLOWED）
• 获取基本存储库
• 使用--no-track标志将基地的master分支检入本地master分支，以断开跟踪链接
• 在项目的配置文件中替换一些占位符（例如README.md中的存储库名称，docker build npm脚本中的存储库名称等）
• 提交并推送本地母版，并将其设置为跟踪原版母版

作为构建脚本的一部分，在可以推送分支并创建PR之前，脚本将检查此存储库是否是从基本存储库创建的（基于回购中的文件工件），如果是，则检查是否有git fetch base && git log --oneline --exit-code master..base/master > /dev/null的回购中没有的基准变更。如果有任何更改，您的构建将失败，并提示您运行一个单独的脚本以从基础进行更新。

这具有使同步自动进行的好处，因为如果不将配置更新为最新版本就无法对项目进行更改，并且唯一需要更新配置的时间就是您要进行更改和重新构建。

另一方面，它也有缺点。至少可以这样说，这是令人烦恼的，您仅发现在进行更改并运行构建脚本之后，您必须与基本之后进行同步。您可能记得在进行更改之前手动运行检查，但是老实说，这不会发生。现在，您需要提交更改，运行脚本以从基础进行更新，推送并创建PR，等待其合并，拉下一个新的master，然后重新进行基础/合并以更新您的分支-所有这些都可以推动您的简单变化。当变更至关重要且需要投入生产时，这确实是一个痛苦。

另一个缺点是，远程不跨机器同步。因此，如果我只是git clone个应用程序之一，那么我没有设置基本的远程程序，因此构建脚本将失败，因为它无法对照未知的远程程序进行检查。我们使用内部CLI应用程序中的另一个脚本解决了此问题，该脚本用于克隆并自动设置基本远程服务器，但是我不知道允许开发人员对存储库具有写访问权但无法克隆的方法它（并且只能以编程方式允许）-无论如何，不​​在GitHub上。

我希望有人能提供更好的答案。

,

这是一个很酷的问题。我觉得我们有一个不错的解决方案，可以避免重复工作。我们在eslintrc包含的文件夹中的仓库之间共享prettierrc和.gitignore。 package.json脚本指向该文件夹中的配置文件。

这不是它自己的仓库，我们使用husky pre-commit钩子来运行lint和格式化脚本。进行PR时我们不运行它（也许我们应该这样做）。现在，没有什么可以阻止您使用no-verify标志来提交错误的代码，但是代码审查应该可以解决这个问题。