在进行git合并时是否可以排除特定的提交？

假设我想从发布分支合并到主分支,并且在发布分支中有一些我不希望包含在主分支中的提交.有没有办法进行合并,以便一个或多个提交不会合并？

到目前为止,我的策略是执行以下操作(在掌握中):

git merge --no-commit release-branch
# Resolve conflicts and apply reverse patch of the commits that I don't want included
git commit # Edit commit message so that it lists the commits that have been reverse-patched

有一个更好的方法吗？

1> fcurella..：

---

我在Pro Git书中找到了适合我的解决方案.

假设您要排除该文件config.php.

在分支A上:

.gitattributes使用以下行创建在同一目录中命名的文件:config.php merge=ours.这告诉git在合并文件时使用什么策略.在这种情况下,它始终保持您的版本,即.您正在合并的分支上的版本.

添加.gitattributes文件并提交

在分支B上:重复步骤1-2

现在尝试合并.您的文件应保持不变.

---

由于某些原因,这对我不起作用.我创建了一个新的分支,其中包含更改文件的提交,并在两个分支中添加了.gitattributes文件.当我合并回原始分支时,它似乎完全忽略了.gitattributes中的行,并且无论如何都会拉入更改的文件.有什么设置我不见了？

---

这只有在修改了两个文件时才有效,否则忽略merge

---

@robbles你可能会错过这个:http://stackoverflow.com/a/14099431/6309

---

@robbles Caumons是对的.基本上,只有在存在合并冲突时才会触发此属性.在您的情况下,您有一个FF合并.Git只是在没有检查合并策略的情况下完成

2> Dustin..：

---

创建一个新分支,以交互方式重新分支该分支并删除您不想要的提交,然后合并它.

如果没有重新划分,你不能从分支的中间进行更改,但是当它在后来的合并中看到相同的变化时会发生正确的事情(例如,从采摘樱桃和什么不是).

---

@Henning当你'git rebase -i other-branch`时,它会为你提供一个文本编辑器,里面有一堆提交.删除不需要的行.

---

有哪些确切的命令要做？我认为我无法"删除"不需要的提交

---

但是,当您尝试再次合并该分支时会发生什么？

3> Tobias Schul..：

---

如果您有一个支持分支,您可以在其中修复错误并构建新版本.在master上你有下一个版本,你也可以经常构建新版本.

每次构建新版本时,都要更改某个文件中的版本,提交新文件,创建标记并推送.现在从支持到master的合并将始终在包含版本信息的文件中存在冲突.

如果包含版本信息的文件仅包含版本信息,则可以使用fcurella的答案.但如果它确实也可能包含可合并信息(pom.xml,gradle.properties,MANIFEST.MF,...),则必须执行一些额外的操作.

让我们使用以下示例

      C---D*---E---F* support
     /
A---B---G---H*---I master

其中明星提交仅包含由于版本更改而导致的更改,这些更改应在合并期间忽略.

要将支持合并到master而不会因版本构建而发生合并冲突,您可以执行以下任一操作:

多个合并提交

git checkout master
git merge C
git merge D -s ours
git merge E
git merge F -s ours

有了这个-s ours参数,我们告诉git只记录合并而不改变工作区.这与svn 的--record-only选项相当.

以上将导致以下布局

      -------------C---D*---E---F* support
     /              \   \    \   \
A---B---G---H*---I---J---K----L---M master

一个合并提交使用cherry-pick

git checkout master
git merge support -s ours --no-commit
git cherry-pick C E --no-commit
git commit -m 'merged support into master'

首先,我们开始合并,但只记录我们正在合并,而不改变工作空间,也不进行合并提交.然后,我们正在挑选合并的提交,再次没有提交.最后我们正在进行合并.

以上将导致以下布局

      C---D*---E---F* support
     /              \
A---B---G---H*---I---J master

人们甚至可以自动采摘樱桃.

git checkout master
git merge support -s ours --no-commit
for id in `git log support --reverse --not HEAD --format="%H [%an] %s" |
  grep -v "bump version" |
  sed "s/\(\w*\)\s.*/\1/g"`
do
  git cherry-pick --no-commit $id
done
git commit -m 'merged support into master'