git自动重命名合并文件 [英] git automatically rename merged files
问题描述
我想创建一个存储库，它是两个现有存储库的组合。
这两个repo基本上没有耦合，但有几个元文件显示在这两个回购，主要是.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 -mrepoa
mkdir repob
cd repob
git init
touch .gitignore
touch README.md
mkdir bdir
touch bdir / bfile
git add -A
git commit -mrepob
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
此时我们会收到冲突讯息。 p>
有没有在 git init for repoab和 git pull 之间的方式，我可以告诉repoab自动重命名README从repoa到READMErepoa.md的.md和从repob到READMErepob.md的README.md。
<.gitignore文件带来了更多的复杂性。基本上，repoab中的.gitignore文件应该是repoa / .gitignore与repob / .gitignore的组合以及一些repoab规则。这里的一个完美场景是，我使用与README.md文件相同的重命名策略，repoa / .gitignore成为repoab / .gitignorerepoa，与repob类似。然后，如果有某种方式将文件包含在repoab / .gitignore中。
我问了一个问题，昨天有关.gitignore文件夹的可能性，其中包含多个.gitignore文件，我相信这些文件可以解决这种情况，但它没有引起太多关注。 p>
另一个野兽是.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 /
这个应用程序的工作原理与foo相同，但它也允许添加插件。
我设计了我的应用程序，以便您可以创建一个插件而不修改任何myapplication的代码，当它运行时，main.p将获取它在插件目录中找到的任何插件，插件将负责他们自己的模型/视图/控制文件。
现在我想开始研究我的新插件plugina。
myapplication / $而不是克隆我的应用程序并开始工作，我可以为plugina创建一个存储库，该存储库包含以下内容。 b $ b --README.md
- 。gitignore
- 。gitattributes
- 模型/
- plugina.m
- 查看/
---- 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
- 插件/
---- plugina.p
不是一个大问题，我处理冲突并且可以继续开发。然而，冲突无疑会降低我提交或更新代码的次数，因为我知道我有这个障碍。
使用这种技术，我可以拥有大量的插件，而我可以使用任意随机的插件集创建一个myapplication版本。由于我使用的是存储库而不是复制/粘贴插件代码，因此我可以在使用它们的任何回购中为我的插件提供版本控制的所有优势，如果发现全局问题，我可以使插件保持最新状态这个插件我可以将它推回到插件仓库，如果插件更新不能在这个仓库中使用，我可以把它推回去。
整个工作流程都持续回到这些不断合并冲突的相当小的障碍之后。 解决方案
Git不是为这类事情而构建的。您将不断地合并来自回购A和B的冲突，即使有办法设置您想要的规则，也可能不会有比脚本更多的工作来执行您的重命名和连接描述。
您可以使用 Git子模块。这可以让您将repo A和repo B放入repo AB的子目录中。他们在这些子目录中保持完全独立，但是repo AB保持其状态 - 基本上，AB会跟踪每个版本的哪个版本被检出。
I want to create a repository that is the combination of two existing repositories.
The two repo's are largely uncoupled however there are a few meta files that show up in both repos, mainly .gitignore, .gitattributes and README.md.
The following would basically reproduce my situation.
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
At this point we will receive the conflict message.
Is there some way, between the git init for repoab and the git pull's that I can tell repoab to automatically rename the README.md from repoa to READMErepoa.md and the README.md from repob to READMErepob.md.
Further complexity arises with the .gitignore files. Essentially the .gitignore file in repoab should be the combination of repoa/.gitignore with repob/.gitignore as well some rules for repoab. A perfect scenario here would be that I use the same rename strategy as for the README.md files, repoa/.gitignore becomes repoab/.gitignorerepoa, similar for repob. Then if there were some way to include the files in the repoab/.gitignore.
I asked a question yesterday about the possibility of .gitignore folders, containing multiple .gitignore files which I believe would solve this situation but it didn't garner much attention.
Another beast altogether is the .gitattribute's files, I would be looking for a union of the 3 files (repoa/.gitattributes + repob/.gitattributes + repoab/.gitattributes). A .gitattributes folder may be useful here as well.
So the issue is that I have several of these simple conflict resolutions. It's no big deal to merge the files once. However I'm going to end up with the same conflicts every single time I pull from either repo. I'm not sure if I would also end up with problems because committing repoab/.gitignore will put repoab's version of .gitignore ahead of repoa and repob.
Update: An example of where I think this sort of meta-file management could be useful
Suppose I have an application modeled by MVC with the following simple directory tree.
myapplication/
--README.md
--.gitignore
--.gitattributes
--main.p
--model/
----myapplication.m
--view/
----myapplication.v
--control/
----myapplication.c
--plugins/
This application works and does foo but it also allows for plugins to be added.
I've designed myapplication so that you can create a plugin without modifying any of the code for myapplication, when it runs, main.p will grab any plugins it finds in the plugins directory, the plugins will be responsible for their own model/view/control files.
So now I want to start working on my new plugin, plugina. Rather than cloning myapplication and starting to work, I can create a repository for plugina, this repository contains the following.
myapplication/
--README.md
--.gitignore
--.gitattributes
--model/
----plugina.m
--view/
----plugina.v
--control/
----plugina.c
--plugins/
----plugina.p
Now I create a new repository that will be used for developing and testing plugina.
This repository is the merger of myapplication and plugina, created in the same manor as I created repoab above. This is where I have my merge conflicts with .gitignore and 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
Not a huge problem, I handle the conflict and can continue dev. The conflicts however undoubtedly lower the number of times I commit or update code, knowing that I have that hurdle.
With this technique I can have a large number of plugins and I can create a version of myapplication with any random collection of plugins. Since I'm using repositories rather than copy/pasting plugin code I can have all the benefits of version control for my plugins in any repo that makes use of them, I can keep the plugins up to date, if I find a global issue with the plugin I can push it back to the plugin repo, if a plugin update doesn't work with this repo I can roll it back.
This whole workflow is just held back by the fairly trivial hurdle of these constant merge conflicts.
Git isn't built for this sort of thing. You're going to constantly have merge conflicts coming from repos A and B, and even if there were a way to set up the rules you want, it would probably be no more work than a script to perform the renames and concatenations you're describing.
The closest thing you can get is using Git submodules. This lets you put repo A and repo B into subdirectories in repo AB. They remain totally independent in those subdirectories, but repo AB maintains their state - basically, AB tracks which version of each is checked out.
这篇关于git自动重命名合并文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
