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 个补丁，省略“提交 M”。我该如何处理？

-杰弗里·李

Answer 1

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

参见 Jeff King (peff) 的 commit 8e0601f（2021 年 5 月 1 日）。
^{（由 Junio C Hamano -- gitster -- 合并到 commit 270f8bf，2021 年 5 月 11 日）}

docs/format-patch: 提及合并处理

^{签字人：杰夫·金}

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

git format-patch 现在包含在其man page 中：

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

git format-patch 现在包含在其man page 中：

注意事项

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

Answer 2

似乎没有产生单个提交的解决方案 à la git format-patch，但 FWIW，您可以格式化包含有效合并提交的补丁，适合/兼容 git am：

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

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 --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 3

根据 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|^\([^ ]*\) \(.*\)|\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 一起使用，那么您将需要排除任何空的合并提交，否则您将收到错误“补丁为空。是否拆分错误？”。

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

如果您检查前两个补丁的内容，您会发现问题：

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 6

请注意，一个裸露的git log -p 不会显示合并提交“M”的任何补丁内容，但使用git log -p -c 会哄它出来。但是，git format-patch 不接受与git log 接受的-c（或--combined、-cc）类似的任何参数。

我也很困惑。