如何从合并中排除文件？
我刚刚开始了解git，目前正在考虑合并。假设我有一个主分支，并且我创建了一个名为child of this的分支。我在子分支上工作，还修改了一些文件。现在我想将这个子分支合并到主分支中：
git merge child但是，在子分支中(也在主分支中)有一些我不想合并的文件。如何将子项中的更改合并到主文件中，但从子项中排除特定文件？
回答 2
Stack Overflow用户
发布于 2016-06-27 08:42:12
简短的答案很简单:不。
长长的答案要复杂得多，但也等同于“不”。本质上，在某些情况下，你可以让Git相信，如果合并的两端都有变化，那么这些变化总是冲突的。请参阅相关问题的this answer (尽管我真正要说的是，您可以将文件标记为二进制文件，或者设置特殊的合并驱动程序，但即使到了这一步，您也需要了解很多背景知识)。
如果你想避免某些文件，你可以做的就是用--no-commit运行你的git merge
$ git status
On branch master
nothing to commit, working directory clean
$ git checkout -b sidebranch
... lots of coding, git committing, etc
$ git checkout master
... more coding and committing, etc.,
or various merges of other branches,
so that master and sidebranch are
actually divergent (if they are
not, note that merge would
normally do a "fast forward" here)
$ git merge --no-commit sidebranch在这一点上，Git将使用我在链接答案中描述的过程进行合并(通过执行两个差异，然后组合两个差异)。但它不会自动提交结果合并，即使它成功了。
这意味着您现在可以执行以下操作：
$ git rm path/to/ickyfile
# we don't want this file, it's icky!和/或这个：
$ git checkout --ours -- path/to/foo; git add path/to/foo
# we want the current (master) version of this file,
# ignoring all the changes made in the side branch甚至像这样的东西(但不要:结果有时被称为“邪恶的合并”)：
$ vim path/to/bar
<make changes that come from neither master nor sidebranch>
$ git add path/to/bar一旦你完成了把坏的事情变成好的合并:-)你可以运行git commit来完成合并。
一般来说，如果你发现你需要这样做，你可能使用了错误的工具。尤其是，人们经常在配置文件中这样做，而“正确”的事情是不把这些文件放在Git (或任何版本控制系统)中。
(相反，在VCS中放置一个示例配置文件。添加并提交prog.conf.example，而不是prog.conf。将prog.conf放入您的.gitignore。如果需要，您的安装/初始化代码可以将示例配置复制到适当位置，以供新用户设置。)
Stack Overflow用户
发布于 2016-06-27 10:47:25
如果你犹豫合并的原因是你会遇到合并冲突，我认为你不应该这样做。合并冲突解决方案虽然是一项很难学习的任务，但您可以从中受益良多。
但是，如果您现在不想这样做，或者如果您的问题是其他问题，我可以想出几种方法从子分支中排除文件：
方法1.如果对文件的更改是在它们自己的提交中进行的，那么您可以从这些提交中创建补丁，并通过交互式rebase从您的分支中“删除”这些提交，但我对此表示怀疑。但是，如果是，请执行以下操作：
git format-patch -1 commit_in_which_you_modified_the_file假设您的分支有2个提交，执行以下操作：
git rebase -i HEAD~3这将把您带到一个菜单，它看起来像
pick commit_hash_of_1st_commit ...
pick commit_hash_of_2st_commit ...假设您不想添加的文件是第一次提交的一部分，您将通过删除行或注释掉它来“丢弃”第一次提交：
# pick commit_hash_of_1st_commit ...
pick commit_hash_of_2st_commit ...从编辑器中解脱出来，你的分支上应该有你需要的东西。此外，请记住，您有一个补丁，您可以稍后apply它。
Pros:
- logically simple
- idiomatically Git
Cons:
- interactive rebase can be an overwhelming task the first time.方法2.从您的分支中挑选出修改您不想提交的文件的特定提交。通过交互式的rebase，edit这些提交。
假设您的分支有2个提交，执行
git rebase -i HEAD~3这将把您带到一个菜单，它看起来像
pick commit_hash_of_1st_commit ...
pick commit_hash_of_2st_commit ...假设您不想添加的文件是第一次提交的一部分，您将对第一次提交执行edit：
edit commit_hash_of_1st_commit ...
pick commit_hash_of_2st_commit ...在这一点上，逃离你的编辑器。当你这样做的时候，Git会应用第一次提交，但让你在事后edit它。
执行以下操作：
git reset HEAD~1这将取消提交，并取消第一次提交时所做的更改。这使您可以在该提交的上下文中重新开始。
然后：
仅对那些更改进行
git add，然后对其余更改执行wantgit commitgit add：git diff > mypatch.patch
优点：
- 这是正确的方法。
缺点：
第一次使用
- 交互式重定基数可能是一项压倒性的练习。
方法3.将最终提交添加到您的分支，在该分支中，您可以撤消对文件所做的所有更改。您可以参考此最终提交的更改集来重新构建对稍后要排除的文件所做的更改。
Pros:
- easy to do (assuming there aren't too many changes)
Cons:
- corrupts VC history
- is not idiomatic usage of Git方法4.如果您的分支有一个提交，则重新提交，即git reset HEAD~1，并且只重新提交您想要的内容。
Pros:
- it is straightforward, basically a modification of one of the previous methods方法5.创建一个新的分支，然后重新开始。我认为不应该走到这一步，尽管考虑到您的分支的性质，这可能并不困难，而且可能是实用的方法。
https://stackoverflow.com/questions/38044166
复制相似问题
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号