使用git-diff生成补丁文件

我遇到了一些问题来理解为什么git diff生成的补丁文件不同

下面是我的git日志：

local\u tracking\u分支

有一个额外的功能，它没有被推到远程

commit\u HASH\u 1（HEAD->local\u tracking\u分支）

commit\u HASH\u 2（原点/主线、原点/头部）

我使用

git diff mainline>patch1

生成第一个补丁

然后我使用

git diff COMMIT\u HASH\u 1 COMMIT\u HASH\u 2>patch2

生成第二个补丁

原来

patch1

比

patch2

大约10K字节

在这里，我被指示使用第一种方法来生成要发布的补丁，但我想知道使用第二种方法来生成补丁文件是否合适

另一种情况是，一旦我将该功能推入远程主线，我可以使用第二种方法吗

git diff commmit-hash1 commit-hash2

生成有效补丁

谢谢你的解释

我使用的是git diff主线

这种形式的

git diff

比较给定的提交，哈希ID将作为运行的结果：

git rev-parse mainline

这很可能与以下情况大不相同：

git rev-parse origin/mainline

-到当前工作树。更准确地说，它将给定提交中保存的快照与当前工作树（您可以看到的文件）进行比较

我使用

git-diff-COMMIT\u-HASH\u-1-COMMIT\u-HASH\u-2

这种形式的

git diff

将第一次提交中保存的快照与第二次提交中保存的快照进行比较

给定来自

git日志的这些输出片段

：

我们可以预测，

mainline

将解析为第三个提交散列。我们无法确定您当前的工作树是否与

COMMIT\u HASH\u 1

中保存的快照相匹配，但是如果

git status

表示所有内容都是“干净的”，并且没有要提交的内容，则可能与此匹配

因此，所有奇怪之处最有可能的来源是

mainline

指的是某个第三次提交，其快照与名称

origin/mainline

解析的提交中的快照不太相似。（您已经有了该散列ID，但要再次查看它，请使用前面提到的

git rev parse origin/mainline

），但另一种可能是当前工作树与任何和/或所有其他提交不同。由于工作树由普通文件组成，因此任何普通（非Git）命令都可以对这些普通文件进行任意更改

另一种情况是，一旦我将该功能推入远程主线，我可以使用第二种方法

git diff commmit-hash1 commit-hash2

生成有效补丁吗

你可以随时这样做。它的有效性取决于谁有哪个提交以及他们想对这些提交做什么

要记住的是，名字会随着时间的推移而改变。像

mainline

或

origin/mainline

这样的名称指的是通过散列ID进行的一些提交。您可以使用

git rev parse

找到它们现在命名的名称。明天，在人们使用分支进行操作之后，他们可能会引用不同的提交散列ID

但是，哈希ID永远保持不变。给定任何特定的哈希ID，该哈希ID表示该提交。任何其他提交都不能有该散列ID。该提交的快照将一直冻结；该散列ID将始终以该形式表示这些文件

---

散列ID又长又难看，看起来随机，很难输入。这是我们使用名字的原因之一。然而，分支名称会随着时间的推移而变化。这就是我们使用标记名的一个原因：标记名被设计为稳定的，不会随时间而改变。使用提交散列；或者，使用标记名指定一个特定的提交，并且不要手动移动标记名（Git不会自行移动它们），这样您就可以稳定地引用该特定的提交。

使用更好的工具，也就是说，

git格式补丁

。那么

git-diff-origin/mainline

和

git-diff-mainline

是两种不同的东西吗？谢谢。在这种情况下，是的。如果它们是相同的东西，你会看到，不是

commit-commit-HASH\u2（origin/mainline，origin/HEAD）

，而是

commit-commit-HASH\u2（mainline，origin/mainline，origin/HEAD）

。如果你

git-checkout-mainline

然后

git-merge--ff-only-origin/mainline

，这就成功了，您的

主线

和

起点/主线

将匹配。是否以及何时这样做取决于你。在某些情况下它不会成功；这是好的，坏的，还是漠不关心也取决于你。

commit COMMIT_HASH_1 (HEAD -> local_tracking_branch)
commit COMMIT_HASH_2 (origin/mainline, origin/HEAD)