Git：如何为合并创建补丁？

Question

当我使用 git format-patch 时，它似乎不包含合并。如何执行合并，然后将其作为一组补丁通过电子邮件发送给某人？

例如，假设我合并两个分支并在合并之上执行另一个提交：

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"

这将创建以下树：

    B
  /   \
A       M - D 
  \   /
    C

现在我尝试签出初始提交并重播上述更改：

git checkout -b replay master
git format-patch --stdout master..bar | git am -3

这会产生合并冲突。在这种情况下， git format-patch master..bar 只生成 3 个补丁，省略“Commit M”。我该如何处理这个问题？

——杰弗里·李

Answer 1

似乎没有一个解决方案可以像git format-patch那样生成单独的提交，但是FWIW，您可以格式化包含有效合并提交的补丁，适合/与git am兼容code>：

显然， Git 参考 指南提供了第一个提示：

git log -p 显示每次提交引入的补丁

[...] 这意味着对于任何提交，您都可以获得该提交引入到项目中的补丁。您可以通过运行具有特定提交 SHA 的 git show [SHA] 来完成此操作，也可以运行 git log -p 来执行此操作，这会告诉 Git 将补丁放在每个犯罪。 [...]

现在， git-log 的手册页给出了第二个提示：

git log -p -m --first-parent

...显示历史记录，包括更改差异，但仅从“主分支”角度来看，跳过来自合并分支的提交，并显示合并引入的更改的完整差异。仅当遵循在单个集成分支上合并所有主题分支的严格策略时，这才有意义。

这又意味着具体的步骤：

# Perform the merge:
git checkout master
git merge feature
... resolve conflicts or whatever ...
git commit

# Format a patch:
git log -p --reverse --binary --pretty=email --stat -m --first-parent origin/master..HEAD > feature.patch

并且这可以按预期应用：

git am feature.patch

同样，这不会包含单独的提交，但它会从合并提交中生成一个 git am 兼容的补丁。

---

当然，如果您一开始就不需要 git am 兼容补丁，那么这就简单得多：

git diff origin/master > feature.patch

但我想您已经想到了这一点，如果您登陆此页面，您就会发现实际上正在寻找我上面描述的解决方法/解决方案。 ;)

Answer 2

如果您检查前两个补丁的内容，您将看到问题：

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

从您当时正在处理的分支（foo 和 bar）的角度来看，这两个提交都删除了“初始文件”行并将其替换完全是别的东西。 AFAIK，当您生成具有重叠更改的非线性进程的补丁时，无法避免这种冲突（在这种情况下，您的分支提交了 B 和 C）。

人们通常使用补丁来添加单个功能或修复已知良好的先前工作状态的错误 - 补丁协议根本不够复杂，无法像 Git 本身那样处理合并历史记录。如果你想让别人看到你的合并，那么你需要在分支之间推/拉，而不是回退差异/补丁。

Answer 3

请注意，裸露的 git log -p 不会显示合并提交“M”的任何补丁内容，但使用 git log -p -c 确实可以将其显示出来。但是，git format-patch 不接受任何类似于 -c （或 --combined、-cc< /code>) 被 git log 接受。

我也仍然陷入困境。

Answer 4

扩展 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

补丁将被命名为 xx0001.patch 到 xxLAST.patch

Answer 5

在 Git 2.32（2021 年第 2 季度）中，“format-patch”文档更加清晰：它跳过合并。

请参阅 提交 8e0601f（2021 年 5 月 1 日），作者：杰夫·金 (peff)。
^{（由 Junio C Hamano -- gitster -- 合并于 提交 270f8bf，2021 年 5 月 11 日）}

docs/format-patch：提及处理合并次数

^{签字人：杰夫·金}

Format-patch 没有办法以 git-am （或任何其他工具）可以应用的方式格式化合并，因此它只是忽略它们。
然而，对于不熟悉该工具如何工作的用户来说，这可能是一个令人惊讶的暗示。
让我们在文档中添加一个注释，使这一点更加清晰。

git format-patch 现在包含在其 手册页：

准备每个非合并提交及其“补丁”

使用 git format-patch 现在包含在其 手册页：

注意事项

请注意，format-patch 将省略输出中的合并提交，即使
如果它们属于请求范围的一部分。
一个简单的“补丁”并不
包含足够的信息供接收端重现相同的信息
合并提交。

Answer 6

根据 Philippe De Muyter 的解决方案，我制作了一个版本，该版本以与 git-format-patch 相同的方式格式化补丁（据我所知）。只需将 RANGE 设置为所需的提交范围（例如 origin..HEAD）并执行：

LIST=$(git log --oneline --first-parent --reverse ${RANGE});
I=0;
IFS=
请注意，如果您将其与 git-quiltimport 一起使用，那么您将需要排除任何空的合并提交，否则您将收到错误“补丁为空”是不是分错了？”
\n';
for ITEM in ${LIST}; do
    NNNN=$(printf "%04d\n" $I);
    COMMIT=$(echo "${ITEM}" | sed 's|^\([^ ]*\) \(.*\)|\1|');
    TITLE=$(echo "${ITEM}" | sed 's|^\([^ ]*\) \(.*\)|\2|' | sed 's|[ -/~]|-|g' | sed 's|--*|-|g' | sed 's|^\(.\{52\}\).*|\1|');
    FILENAME="${NNNN}-${TITLE}.patch";
    echo "${FILENAME}";
    git log -p --pretty=email --stat -m --first-parent ${COMMIT}~1..${COMMIT} > ${FILENAME};
    I=$(($I+1));
done

请注意，如果您将其与 git-quiltimport 一起使用，那么您将需要排除任何空的合并提交，否则您将收到错误“补丁为空”是不是分错了？”