我想创建一个存储库，它是两个现有存储库的组合。
这两个repo很大程度上是解耦的，但是有两个元文件出现在两个repos中，主要是.gitignore，.gitattributes和README.md。
以下内容基本上可以重现我的情况。
mkdir repoa
cd repoa
git init
touch .gitignore
touch README.md
mkdir adir
touch adir/afile
git add -A
git commit -m"repoa"
mkdir repob
cd repob
git init
touch .gitignore
touch README.md
mkdir bdir
touch bdir/bfile
git add -A
git commit -m"repob"
mkdir repoab
cd repoab
git init
git remote add repoa /path/to/repoa
git remote add repob /path/to/repob
git pull repoa master
git pull repob master
此时我们将收到冲突消息。
在git init for repoab和git pull之间是否存在某种方式，我可以告诉repoab自动将README.md从repoa重命名为READMErepoa.md和README.md来自repob到READMErepob.md。
.gitignore文件出现了进一步的复杂性。基本上repoab中的.gitignore文件应该是repoa / .gitignore与repob / .gitignore的组合以及repoab的一些规则。这里一个完美的场景是我使用与README.md文件相同的重命名策略，repoa / .gitignore变为repoab / .gitignorerepoa，类似于repob。然后，如果有一些方法将文件包含在repoab / .gitignore中。
昨天我问了一个question关于.gitignore文件夹的可能性，其中包含多个.gitignore文件，我认为这些文件可以解决这种情况，但它没有引起太多关注。
另一个野兽是.gitattribute的文件，我会寻找3个文件的联合（repoa / .gitattributes + repob / .gitattributes + repoab / .gitattributes）。这里的.gitattributes文件夹也很有用。
所以问题是我有几个简单的冲突解决方案。合并文件一次没什么大不了的。但是，每当我从任何一个回购中抽出时，我都会遇到同样的冲突。我不确定我是否也会遇到问题，因为提交repoab / .gitignore会将repoab版本的.gitignore置于repoa和repob之前。
更新：我认为这种元文件管理可能有用的一个例子
假设我有一个由MVC建模的应用程序，其中包含以下简单的目录树。
myapplication/
--README.md
--.gitignore
--.gitattributes
--main.p
--model/
----myapplication.m
--view/
----myapplication.v
--control/
----myapplication.c
--plugins/
此应用程序可以正常运行，但它也允许添加插件。
我设计了myapplication，这样你就可以创建一个插件而无需修改myapplication的任何代码，当它运行时，main.p会抓取它在plugins目录中找到的任何插件，插件将负责自己的模型/视图/控制文件。
所以现在我想开始研究我的新插件plugina。我可以为plugina创建一个存储库，而不是克隆myapplication并开始工作，该存储库包含以下内容。
myapplication/
--README.md
--.gitignore
--.gitattributes
--model/
----plugina.m
--view/
----plugina.v
--control/
----plugina.c
--plugins/
----plugina.p
现在我创建一个新的存储库，用于开发和测试plugina。
此存储库是myapplication和plugina的合并，创建方式与我在上面创建的repoab相同。这是我与.gitignore和README.md
myapplication/
--README.md (CONFLICT with plugina/myapplication)
--.gitignore (CONFLICT with plugina/myapplication)
--.gitattributes
--main.p
--model/
----myapplication.m
----plugina.m
--view/
----myapplication.v
----plugina.v
--control/
----myapplication.c
----plugina.c
--plugins/
----plugina.p
不是一个大问题，我处理冲突并可以继续开发。然而，冲突无疑会降低我提交或更新代码的次数，因为我知道自己遇到了这个障碍。
使用这种技术我可以拥有大量的插件，我可以使用任何随机的插件集创建一个myapplication版本。由于我使用的是存储库而不是复制/粘贴插件代码，因此我可以在使用它们的任何存储库中为我的插件提供版本控制的所有好处，如果我发现全局问题，我可以使插件保持最新状态插件我可以把它推回到插件仓库，如果插件更新不能用于这个仓库，我可以将它回滚。
这整个工作流程都受到这些持续合并冲突的相当微不足道的阻碍。
答案 0 :(得分：0)
Git不是为这类东西而构建的。你将不断有来自repos A和B的合并冲突，即使有办法设置你想要的规则，你可能没有比脚本更多的工作来执行重命名和连接你是描述
最接近的是使用Git submodules。这允许您将repo A和repo B放入repo AB中的子目录中。它们在这些子目录中保持完全独立，但是repo AB保持其状态 - 基本上，AB跟踪哪个版本的每个都被检出。