Git:在合并期间忽略一些文件(将一些文件限制在一个分支)
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/3868491/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Git: ignore some files during a merge (keep some files restricted to one branch)
提问by dbarbosa
I have two branches, A
and B
. Branch A
have a directory examples
with some files that are tracked by git, and these files should notappear on branch B
. In my workflow, I do merge changes made in A
into B
often, which is a problem every time that there is some changes on examples
. For the moment I am doing this manually: erasing the files after the merge or solving conflicts when there was a change to a file that I had already erased.
我有两个分支,A
和B
. 科A
有一个目录examples
与被跟踪的git一些文件,这些文件应该不会出现分支B
。在我的工作流程中,我经常将所做的更改合并A
到B
,这在每次有一些更改时都会出现问题examples
。目前我正在手动执行此操作:在合并后删除文件或在我已经删除的文件发生更改时解决冲突。
Is it possible to ignore these files during a merge? (Or is it possible to keep some files restricted to one branch (A
) or away from one branch (B
)?)
在合并期间是否可以忽略这些文件?(或者是否可以将某些文件限制在一个分支 ( A
) 或远离一个分支 ( B
)?)
Let me try to explain why I am doing this:
A
is a skeleton of a blog (template, scripts, etc), B
is my blog (A
filled with my own posts, images, drafts, etc). A
is public and I am trying to make it generic to others look and use it, but because of this I need some posts there as a showcase/tests (the examples
directory). Every change in A
and is later merged into B
to have this changes on my blog instance -- this way all new examples appear in B
and all deleted examples in B
that have been changed in A
since last merge results in a conflict.
让我试着解释一下我为什么要这样做:
A
是博客的骨架(模板、脚本等),B
是我的博客(A
充满了我自己的帖子、图片、草稿等)。A
是公开的,我试图使其通用,其他人可以查看和使用它,但因此我需要一些帖子作为展示/测试(examples
目录)。每次更改A
和后来合并到B
我的博客实例上进行更改 - 这样所有新示例都会出现,B
并且自上次合并以来所有已删除的示例B
都已更改会A
导致冲突。
回答by David
I found a good answer here: stackoverflow Q332528
我在这里找到了一个很好的答案:stackoverflow Q332528
It uses ideas taken from here: Pro-Git merge strategies
它使用了从这里获取的想法:Pro-Git 合并策略
Here is a copy of it:
这是它的副本:
Let's say you want to exclude the file
config.php
On branch A:
Create a file named '.gitattributes' in the same dir, with this line: config.php merge=ours. This tells git what strategy to use when mergin the file. In this case it always keep your version, ie. the version on the branch you are merging into.
Add the .gitattributes file and commit
On branch B: repeat steps 1-2
Try merging now. Your file should be left untouched.
假设您要排除该文件
config.php
在分支 A:
在同一个目录中创建一个名为“.gitattributes”的文件,使用这一行:config.php merge=ours。这告诉 git 在合并文件时使用什么策略。在这种情况下,它始终保留您的版本,即。您要合并到的分支上的版本。
添加 .gitattributes 文件并提交
在分支 B:重复步骤 1-2
现在尝试合并。您的文件应该保持不变。
Edit:
From the git bookregarding merge=ours
, "One very useful option is to tell Git to not try to merge specific files when they have conflicts, but rather to use your side of the merge over someone else's."
编辑:
从git的书有关merge=ours
,“一个非常有用的选项是通知Git不会尝试合并特定的文件,当他们有冲突,而是超过别人的使用合并的一面。”
So, this answer doesn't apply as well as it might to the question. pjmorse's answerregarding using submodules is good.
所以,这个答案并不适用于这个问题。pjmorse关于使用子模块的回答很好。
Another option would be to use a sub-tree merge, which may have added benefits.
另一种选择是使用子树合并,这可能会带来额外的好处。
回答by rafl
You might find git's rerere
command useful. With that you can record resolutions for certain merge conflicts and reuse them later.
您可能会发现 git 的rerere
命令很有用。有了它,您可以记录某些合并冲突的解决方案,并在以后重用它们。
回答by pjmorse
With your updates: Yes, submodules would be appropriate for this use if all of A fits in a subdirectory of B (or vice versa). An example of submodules using WordPress would be if you have a git repository of Wordpress; you could add a submodule for a theme which would be inside the /wp-content/themes/
directory.
随着您的更新:是的,如果所有 A 都适合 B 的子目录(反之亦然),则子模块将适用于此用途。使用 WordPress 的子模块的一个例子是,如果你有一个 Wordpress 的 git 存储库;您可以为目录中的主题添加一个子模块/wp-content/themes/
。
The documentation for submodulesmight help.
If the files from the two are interleaved, it might be tougher. Most cases where submodules can be used in this way, the application in question was designed to allow for them.
如果来自两者的文件交错,则可能会更困难。大多数可以以这种方式使用子模块的情况下,所讨论的应用程序旨在允许它们。