补丁在 Git 中是如何工作的？答案

【问题标题】：How do patches work in Git?补丁在 Git 中是如何工作的？
【发布时间】：2011-01-06 03:21:57
【问题描述】：

我是 Git 新手，但熟悉 SVN。作为测试，我使用git init 在本地目录中创建了一个存储库。然后我将空存储库（通过 SSH 使用 127.0.0.1，这是我想测试的另一件事）克隆到另一个本地目录。我在存储库 2 中添加了一些文件，我添加了 git add *，最后添加了 git commit -a -m "First source code"。

我现在想使用 git format-patch 创建一个补丁并将其应用到存储库 1。我该怎么做？我知道有一本手册，但这些东西非常复杂，让我想对我的显示器做一些事情。

【问题讨论】：

如果您使用 Git，则几乎不需要经常使用补丁，请在下面查看我的答案
This 文章可能有助于理解补丁的完整过程

标签： git patch

【解决方案1】：

通过以下方式创建您的补丁：

$ git format-patch master --stdout > patch.diff

然后 patch.diff 将包含差异，然后您可以将其发送给其他人以应用：

$ git am < patch.diff

有时，当手册有点密集时，寻找教程是有意义的：

http://luhman.org/blog/2009/09/22/git-patch-tutorial

【讨论】：

应用补丁时出现此错误“致命：以前的变基目录 .git/rebase-apply 仍然存在，但给出了 mbox。”

【解决方案2】：

从最后一次提交（或最后几次提交）创建补丁的最简单方法是使用 format-patch 和一个负数，表示要为以下内容创建补丁的提交数：

git format-patch -1

您将获得一个以提交描述命名的补丁文件。使用am 将其插入另一个存储库：

git am << name_of_patch_file

【讨论】：

只是吹毛求疵；但它不是一个负数，它只是一个指示深度的标志。没有奇怪的魔法发生！如果这更自然，您还可以指定一系列提交，例如git format-patch origin/master.. 等等（请参阅 git rev-parse 手册了解表达这些论点的所有方式）。
在 Windows 上使用 git am name_of_patch_file

【解决方案3】：

如果您使用 Git，那么正确且更简单的方法是通过遥控器：

cd \path\to\repo1
git remote add otherrepo \path\to\repo2
git fetch otherrepo

git log otherrepo/master  ## Find the commit you want to steal in the list

git cherry-pick SOME_SHA1  ## Snag just one commit
git merge otherrepo/master  ## Merge all of the new commits from otherrepo/master

这会将 commits 从一个 repo 迁移到另一个 repo，包括他们的作者和提交消息，并将帮助您解决合并冲突（特别是如果您要移动 > 1 个提交）

【讨论】：

当他的初始回购不一样时，这会起作用吗？所有的提交都会有不同的哈希值，因为它有不同的历史。那么修补不是唯一的方法吗？

【解决方案4】：

使用 GitHub 补丁

将.patch添加到提交URL以获取补丁文件，示例

github.com/git/git/commit/b6b3b6a.patch
像这样修补原始文件：
```
git am /tmp/b6b3b6a.patch
```

使用 GitHub 差异

将.diff添加到提交URL以获取补丁文件，示例

github.com/git/git/commit/b6b3b6a.diff
像这样修补原始文件：
```
git apply -p0 /tmp/b6b3b6a.diff
```

§5.3 Distributed Git - Maintaining a Project

【讨论】：

举个例子很好，但不幸的是该链接不再有效。 :(

【解决方案5】：

您必须转到“存储库 2”，即您要从中创建补丁的那个，然后运行 git-format-patch 来创建补丁： git format-patch master --stdout > name_of_patch_file

然后你进入“repository 1”，也就是你想要应用补丁的那个： git apply name_of_patch_file

有时检查补丁是否会导致问题很有用： git apply --check name_of_patch_file

【讨论】：

【解决方案6】：

随着 Git 2.25（2020 年第一季度），git format-patch 演变为更好地使用分支描述（“git branch --edit-description”）作为主题。

参见Denton Liu (Denton-L)commit bf8e65b、commit a92331d、commit 46273df（2019 年 10 月 15 日）。
^{（由 Junio C Hamano -- gitster -- 合并于 commit b75ba9b，2019 年 11 月 10 日）}

format-patch：教--cover-from-description选项

^{签字人：Denton Liu}

以前，当format-patch 生成求职信时，只有正文会填充分支的描述，而主题会填充占位符文本。

但是，用户可能希望以相同的方式自动填充求职信的主题。

教格式补丁接受--cover-from-description 选项和相应的format.coverFromDescription 配置，允许用户填充求职信的不同部分（现在包括主题）。

git config documentation 现在包括：

format.coverFromDescription:
format-patch 的默认模式，用于确定将使用分支描述填充求职信的哪些部分。

还有git format-patch：

--cover-from-description=<mode>:
控制求职信的哪些部分将使用分支机构的描述自动填充。

如果 <mode> 是 message 或 default，则求职信主题将填充占位符文本。
求职信的正文将填充分支的描述。这是未指定配置或命令行选项时的默认模式。

如果<mode> 是subject，则分支描述的第一段将填充求职信主题。
说明的其余部分将填充求职信的正文。

如果<mode>为auto，如果分支描述的第一段大于100字节，则模式为message，否则使用subject。

如果 <mode> 是 none，则求职信主题和正文都将填充占位符文本。

【讨论】：

format-patch：教--cover-from-description选项

`format-patch`：教`--cover-from-description`选项