假设我想从发布分支合并到主分支，并且发布分支中有一些我不想包含在主分支中的提交。有没有办法进行合并，这样一个或多个提交就不会被合并？
到目前为止，我的策略是执行以下操作（在 master 中）：
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
有没有更好的方法来做到这一点？
【问题讨论】：
标签： git
主要问题是：你想如何表示你想跳过的提交？
很遗憾，没有。 2 在历史图中是不可能表达的。
没有。 1 是可能的，但我从不 这样做：合并提交可以包含更改。 – 通常合并提交指向另外两个分支合并的结果：在这些分支中开发的所有内容都应该在合并后的代码中（即在合并提交指向的代码中）。此提交中不应包含其他任何内容。
但令人惊讶的是，您可以更改整个代码库并将其表示为合并。合并的效果是双重的：它合并了历史树和它应该合并两个代码库。前者肯定会（否则没有人称其为合并），后者可能会失败，例如当发生合并冲突并错误解决时（然后代码库未正确合并）。
其他一些答案暗示了这种隐藏。我推荐显式方式：merge plus revert commits。
【讨论】：
如果您有一个支持分支，您可以在其中修复错误并构建新版本。在 master 上，你有下一个版本，你也经常构建新版本。
每次构建新版本时，您都会更改某个文件中的版本，提交该新文件，创建标签并推送。现在从 support 到 master 的合并在包含版本信息的文件中总是会发生冲突。
如果包含版本信息的文件仅包含版本信息，则可以选择 fcurella 的答案。但如果它确实也可能包含可合并信息（pom.xml、gradle.properties、MANIFEST.MF、...），则必须执行一些额外的操作。
让我们使用以下示例
C---D*---E---F* support
/
A---B---G---H*---I master
带有星号的提交仅包含由于版本更改而导致的更改，在合并期间应忽略这些更改。
要将 support 合并到 master 中而不会因版本构建而产生合并冲突，您可以执行以下任一操作：
git checkout master
git merge C
git merge D -s ours
git merge E
git merge F -s ours
使用 -s ours 参数，我们告诉 git 只记录合并而不改变工作区。这相当于to the --record-only option of svn。
以上将导致以下布局
-------------C---D*---E---F* support
/ \ \ \ \
A---B---G---H*---I---J---K----L---M master
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'
【讨论】：
我找到了适合我的解决方案in the Pro Git book。
假设您要排除文件config.php。
在分支 A：
在同一目录中创建一个名为 .gitattributes 的文件，其中包含以下行：config.php merge=ours。这告诉 git 在合并文件时使用什么策略。在这种情况下，它始终保留您的版本，即。您要合并到的分支上的版本。
添加.gitattributes文件并提交
在分支 B：重复步骤 1-2
立即尝试合并。您的文件应保持原样。
【讨论】：
也可以修改 .git/info/attributes 文件并将其保存在 .git 文件夹中，而不是到处添加 .gitattribute 文件，这最终需要将它们添加到源代码管理中。
【讨论】：
如果你只想排除一些最后的提交，你可以只提交一个特定的提交号：
git checkout partlyMergedFrom
git whatchanged
--> find the commit hash up to where you want to merge
git checkout partlyMergedInto
git merge e40a0e384f58409fe3c864c655a8d252b6422bfc
git whatchanged
--> check that you really got all the changes you want to have
【讨论】：
不能直接这样做的原因是每个提交都包含指向父提交的链接（通常只有一个，但有几个用于合并）。这样，如果你有一个提交（通过它的 SHA1 总和），整个历史也被固定，因为父母也包含到他们父母的链接等等。因此，在历史中遗漏补丁的唯一方法是编写一个新补丁。在新创建的分支上执行 git rebase -i 可能是实现这一目标的最简单方法。
【讨论】：
创建一个新分支，以交互方式重新设置分支并删除您不想要的提交，然后将其合并。
如果不重新散列，您不能从分支中间取出更改，但是当它在以后的合并中看到相同的更改时（例如，来自樱桃采摘和其他什么），正确的事情就会发生。
【讨论】：
git rebase -i other-branch 它为你提供了一个包含大量提交的文本编辑器。删除不需要的行。