我是多年使用git的高级用户。最近，我发现自己遇到以下问题，并且似乎无法在线找到描述/解决方案，这使我认为也许我正在尝试以错误的方式解决问题：
我有20个python仓库。我似乎在存储库之间重复了很多东西（mypy.ini文件，flake8配置文件，在进行了一些健全性检查后在docker容器中运行所有测试的文件，setup.py文件）。这些文件在所有存储库之间都是90％相同，只有很小的（预期的）更改；发生了相当多的更改，因为我在1个repo中改进了一些东西，然后没有时间将更改移到所有其他存储库中。
我最近花了一些时间清理所有内容，现在我有1套“基本”文件，这些文件应该存在于所有存储库（以及所有新存储库）中。我可以将其复制到所有存储库中，但这意味着，对于每一个小的改进，我都需要手动将其复制到所有其他存储库中（并检查该存储库中的文件未更改，或者合并更改）。 / p>
我想出的解决方案：
我做了一个仓库base；在这里，我提交这些文件。
在每个回购中，我都合并到基础中：
git remote add base git@github.com/XXXX/base.git
git config remote.base.pushurl "you really didn't want to do that" # make sure one cannot accidentally push to base
git fetch base
git merge base/master --allow-unrelated-histories -m "merging base" --no-fast-forward
git push
现在，当我在基础库中更新某些内容时，我可以通过合并将其合并，以便在我自己闲暇时回显回购（例如，无论如何我正在处理该回购协议）
git fetch base
git merge base/master
git push
它将（应该）做git擅长的事情：检查自上次合并以来基准库中发生了什么变化，查看是否有任何局部更改会导致冲突，合并整个事情，并且只有在我有某些事情时才打扰我需要提供输入（合并冲突）。
现在，这种方法困扰着我
- 也许我看起来还不够好，但是我找不到在线描述此策略的人，这让我觉得可能是有一些原因不应该使用它的原因。 我想念什么？
- 我对git“崩溃合并”存在一些问题。我的意思是合并（以及一些提交和合并）后，事情应该像这样：
master -----*---*---*---*---*---*----*----*----*-----*---------*----*----*----*---*
/ / /
base/master --*--------*---------------*---------------*-----*---*---------*
（因此，在这种情况下，base / master会合并到master中3次，最新的commit合并尚未合并）
但是我得到的（有时；不确定何时获得）是
master -----*---*---*---*---*---*----*----*----*-----*---------*----*----*----*---*
base/master --*--------*---------------*---------------*-----*---*---------*
这些更改在主服务器中进行，但是不是来自基础服务器/主服务器的合并。这意味着下次我尝试进行合并时，系统会抱怨这两个分支没有共享历史记录。 现在我的直觉是，这是因为在初始合并之后，--no-fast-forward命令中没有git merge。这种预感是正确的吗？如果是这样，那现在就很容易解决，但是如果下次我忘记添加--no-fast-forward时如何避免完全弄乱我的历史记录？