git自动重命名合并文件

Question

我想要创建一个存储库，它是两个现有存储库的组合。

这两个回购程序基本上是不耦合的，但是在两个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 pulls之间是否有某种方式，我可以告诉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中。

昨天我问了一个问题关于.gitignore文件夹的可能性，其中包含了多个.gitignore文件，我认为这些文件可以解决这种情况，但没有引起太多的注意。

另一个猛兽是..gitattributes的文件，我将寻找这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/

这个应用程序工作和做foo，但它也允许插件被添加。

我设计了我的应用程序，这样您就可以在不修改我的应用程序的任何代码的情况下创建一个插件，当它运行时，main.p会抓取它在plugins目录中找到的任何插件，插件将负责它们自己的模型/视图/控制文件。

所以现在我想开始我的新插件，plugina。我可以为plugina创建一个存储库，而不是克隆我的应用程序并开始工作，这个存储库包含以下内容。

myapplication/
--README.md
--.gitignore
--.gitattributes
--model/
----plugina.m
--view/
----plugina.v
--control/
----plugina.c
--plugins/
----plugina.p

现在，我创建了一个新的存储库，用于开发和测试plugina。

这个存储库是我的应用程序和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

不是一个大问题，我处理冲突，可以继续开发。然而，冲突无疑降低了我提交或更新代码的次数，因为我知道我有这个障碍。

有了这种技术，我可以拥有大量的插件，我可以创建一个版本的我的应用程序与任何随机的插件集合。由于我使用的是存储库而不是复制/粘贴插件代码，所以在任何使用插件的回购程序中，我都可以获得插件版本控制的所有好处，因此我可以保持插件的最新更新，如果我发现插件存在全局问题，我可以将其推回插件回购，如果插件更新与此回购不兼容，我可以回滚它。

整个工作流只是被这些持续合并冲突的微不足道的障碍所阻碍。

Answer 1

Git不是为这类东西而建造的。您将经常有来自repos和B的合并冲突，即使有一种方法来设置您想要的规则，它可能也不过是一个脚本来执行您所描述的重命名和连接。

您能得到的最接近的东西是使用Git子模。这允许您将回购A和回购B放在回购AB的子目录中。它们在这些子目录中仍然完全独立，但是repo AB维护它们的状态-基本上，AB跟踪每个子目录的哪个版本被检出。