Git：如何为合并创建补丁？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/2285699/
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: How to create patches for a merge?
提问by geofflee
When I use git format-patch, it doesn't seem to include merges. How can I perform a merge and then e-mail it to someone as a set of patches?
当我使用时git format-patch，它似乎不包括合并。如何执行合并，然后将其作为一组补丁通过电子邮件发送给某人？
For example, let's say that I merge two branches and perform another commit on top of the merge:
例如，假设我合并了两个分支并在合并之上执行另一个提交：
git init
echo "initial file" > test.txt
git add test.txt
git commit -m "Commit A"
git checkout -b foo master
echo "foo" > test.txt
git commit -a -m "Commit B"
git checkout -b bar master
echo "bar" > test.txt
git commit -a -m "Commit C"
git merge foo
echo "foobar" > test.txt
git commit -a -m "Commit M"
echo "2nd line" >> test.txt
git commit -a -m "Commit D"
This creates the following tree:
这将创建以下树：
B
/ \
A M - D
\ /
C
Now I try to checkout the initial commit and replay the above changes:
现在我尝试检查初始提交并重放上述更改：
git checkout -b replay master
git format-patch --stdout master..bar | git am -3
This produces a merge conflict. In this scenario, git format-patch master..baronly produces 3 patches, omitting "Commit M". How do I deal with this?
这会产生合并冲突。在这种情况下，git format-patch master..bar只生成 3 个补丁，省略“提交 M”。我该如何处理？
-Geoffrey Lee
-杰弗里·李
采纳答案by omnisis
If you examine the content of the first two patches you'll see the issue:
如果您检查前两个补丁的内容，您将看到问题：
diff --git a/test.txt b/test.txt
--- a/test.txt
+++ b/test.txt
@@ -1 +1 @@
-initial file
+foo
diff --git a/test.txt b/test.txt
index 7c21ad4..5716ca5 100644
--- a/test.txt
+++ b/test.txt
@@ -1 +1 @@
-initial file
+bar
from the perspective of the branch you were working on at the time (foo and bar) both of these commits have removed the "initial file" line and replaced it with something else entirely. AFAIK, there's no way to avoid this kind of conflict when you generate a patch of a non-linear progression with overlapping changes (your branch commits B and C in this case).
从您当时正在处理的分支（foo 和 bar）的角度来看，这两个提交都删除了“初始文件”行并将其完全替换为其他内容。AFAIK，当您生成具有重叠更改的非线性进程补丁时，无法避免这种冲突（在这种情况下，您的分支提交 B 和 C）。
People normally use patches to add a single feature or bug fix off a known good prior work state -- the patch protocol is simply not sophisticated enough to handle merge history like Git does natively. If you want someone to see your merge then you need to push/pull between branches not drop back diff/patch.
人们通常使用补丁来添加单个功能或修复已知良好的先前工作状态的错误——补丁协议根本不够复杂，无法像 Git 本身那样处理合并历史。如果你想让别人看到你的合并，那么你需要在分支之间推/拉而不是回退差异/补丁。
回答by sun
There does not seem to be a solution producing individual commits à la git format-patch, but FWIW, you can format a patch containing the effective merge commit, suitable/compatible with git am:
似乎没有产生单个提交的解决方案 à la git format-patch，但是 FWIW，您可以格式化包含有效合并提交的补丁，适合/兼容git am：
Apparently, the Git Referenceguide provides the first hint:
显然，Git 参考指南提供了第一个提示：
git log -pshow patch introduced at each commit
[...] That means for any commit you can get the patch that commit introduced to the project. You can either do this by running
git show [SHA]with a specific commit SHA, or you can rungit log -p, which tells Git to put the patch after each commit. [...]
git log -p显示每次提交时引入的补丁
[...] 这意味着对于任何提交，您都可以获得该提交引入项目的补丁。您可以通过运行
git show [SHA]特定的提交 SHA来执行此操作，也可以运行git log -p，它告诉 Git 在每次提交后放置补丁。[...]
Now, the manual page of git-loggives the second hint:
现在，git-log的手册页给出了第二个提示：
git log -p -m --first-parent... Shows the history including change diffs, but only from the "main branch" perspective, skipping commits that come from merged branches, and showing full diffs of changes introduced by the merges. This makes sense only when following a strict policy of merging all topic branches when staying on a single integration branch.
git log -p -m --first-parent... 显示包括更改差异的历史记录，但仅从“主分支”的角度来看，跳过来自合并分支的提交，并显示合并引入的更改的完整差异。只有在遵循合并所有主题分支并停留在单个集成分支上的严格策略时，这才有意义。
Which in turn means in concrete steps:
这反过来意味着具体步骤：
# Perform the merge:
git checkout master
git merge feature
... resolve conflicts or whatever ...
git commit
# Format a patch:
git log -p --reverse --pretty=email --stat -m --first-parent origin/master..HEAD > feature.patch
And this can be applied as intended:
这可以按预期应用：
git am feature.patch
Again, this won't contain the individual commits, but it produces a git amcompatible patch out of a merge commit.
同样，这不会包含单个提交，但它会git am从合并提交中生成一个兼容的补丁。
Of course, if you don't need a git amcompatible patch in the first place, then it's way simpler:
当然，如果您一开始就不需要git am兼容的补丁，那么就简单多了：
git diff origin/master > feature.patch
But I guess you already figured as much, and if you landed on this page here, you are actually searching for the workaround/solution I've described above. ;)
但我想您已经想清楚了，如果您在这里登陆此页面，您实际上是在寻找我上面描述的变通方法/解决方案。;)
回答by seh
Note that a bare git log -pwon't show any patch content for the merge commit "M", but using git log -p -cdoes coax it out. However, git format-patchdoesn't accept any arguments analogous to the -c(or --combined, -cc) accepted by git log.
请注意，baregit log -p不会显示合并提交“M”的任何补丁内容，但使用git log -p -c会哄骗它。但是，git format-patch不接受任何类似于-c(或--combined, -cc) 接受的参数git log。
I too remain stumped.
我也仍然难倒。
回答by Philippe De Muyter
Expanding sun's answer, I came to a command that can produce a series of patches similar to what git format-patchwould produce if it could, and that you can feed to git amto produce an history with the individual commits :
扩展sun的答案，我来到了一个命令，它可以生成一系列补丁，类似于git format-patch如果可以生成的补丁，并且您可以提供这些补丁git am以生成具有单个提交的历史记录：
git log -p --pretty=email --stat -m --first-parent --reverse origin/master..HEAD | \
csplit -b %04d.patch - '/^From [a-z0-9]\{40\} .*$/' '{*}'
rm xx0000.patch
Patches will be named xx0001.patchto xxLAST.patch
补丁将被命名xx0001.patch为xxLAST.patch
回答by Compholio
Working from Philippe De Muyter's solution I made a version that formats the patches the same way as git-format-patch (as far as I can tell). Just set RANGE to the desired range of commits (e.g. origin..HEAD) and go:
使用 Philippe De Muyter 的解决方案，我制作了一个版本，该版本以与 git-format-patch 相同的方式格式化补丁（据我所知）。只需将 RANGE 设置为所需的提交范围（例如 origin..HEAD）然后去：
LIST=$(git log --oneline --first-parent --reverse ${RANGE});
I=0;
IFS=$'\n';
for ITEM in ${LIST}; do
NNNN=$(printf "%04d\n" $I);
COMMIT=$(echo "${ITEM}" | sed 's|^\([^ ]*\) \(.*\)||');
TITLE=$(echo "${ITEM}" | sed 's|^\([^ ]*\) \(.*\)||' | sed 's|[ -/~]|-|g' | sed 's|--*|-|g' | sed 's|^\(.\{52\}\).*||');
FILENAME="${NNNN}-${TITLE}.patch";
echo "${FILENAME}";
git log -p --pretty=email --stat -m --first-parent ${COMMIT}~1..${COMMIT} > ${FILENAME};
I=$(($I+1));
done
Note that if you are using this with git-quiltimport then you will need to exclude any empty merge commits or you will get the error "Patch is empty. Was it split wrong?".
请注意，如果您将它与 git-quiltimport 一起使用，那么您将需要排除任何空的合并提交，否则您将收到错误“补丁为空。是否拆分错误？”。
