如何获取拉取请求的提交和文件列表？（不是通过用户界面）

Question

我正在尝试获取git log与拉取请求类似的日志信息，但其中包含专门针对拉取请求的信息。我想获取刚刚合并到已更改的主文件中的拉取请求。

例如，我有一个刚刚合并的拉取请求。它更改了 File1、File2 和 File4。

我还有另一个刚刚合并的拉取请求。它改变了 File1、File3。

我希望能够获得与特定拉取请求相关联的文件的名称。

我的问题是git log --onelineor git whatchanged -morgit log --pretty=format:"%H" --name-only没有按顺序显示内容，并且由于提交而很难解析。

有没有办法检索从拉取请求中编辑的文件？

Answer 1

TL; 博士

你可能想要：

git diff-tree [options] <sha>^1 <sha>

例如，由：

$ git diff-tree --abbrev bdae4af8705^1 bdae4af8705
:100644 100644 50c6b2ab1... 8cc34186c... M      setup.c
$ git diff-tree --name-status bdae4af8705^1 bdae4af8705
M       setup.c

长

嗯，首先，区分pull request很重要，这不是 Git 定义的，¹和合并提交，这是。就 Git 而言，拉取请求只是任何其他提交。在合并之前，您必须以某种方式找到或指定第二次提交。您所看到的是已经在某个网页上单击了一些标记为“合并拉取请求”的可点击按钮的后果。

我说这一切不是迂腐，²，但因为这是一件好事，因为它意味着你现在有一个合并提交您已经通过运行获得git fetch。（如果您还没有使用git fetch过获取合并提交，请先这样做。）这简化了问题！不必搜索所有合并的提交，您只需查看合并提交本身：

……git whatchanged -m不按顺序显示东西……

使用git log -m-git whatchanged实际上就是git log --raw这样你正在这样做 - 是一种要走的路。我不清楚您所说的“不按顺序显示事物”是什么意思：事实上，它以非常精确和受控的顺序显示事物，正如我们通过运行可以看到的，例如：

git log --raw -m bdae4af87053490adad2dc9fb184d6d050d46a4c

在 Git 的 Git 存储库上：

$ git log --raw -m bdae4af87053490adad2dc9fb184d6d050d46a4c
commit bdae4af87053490adad2dc9fb184d6d050d46a4c (from 8d7fefaac4318ac3155368f475e10f97714ebd47)
Merge: 8d7fefaac 176b2d328
Author: Junio C Hamano <gitster@pobox.com>
Date:   Tue Dec 19 11:33:58 2017 -0800

    Merge branch 'sg/setup-doc-update'

    Comment update.

    * sg/setup-doc-update:
      setup.c: fix comment about order of .git directory discovery

:100644 100644 50c6b2ab1... 8cc34186c... M      setup.c

commit bdae4af87053490adad2dc9fb184d6d050d46a4c (from 176b2d328ccc305aa2e565c39ad7b0fb24099275)
Merge: 8d7fefaac 176b2d328
Author: Junio C Hamano <gitster@pobox.com>
Date:   Tue Dec 19 11:33:58 2017 -0800

    Merge branch 'sg/setup-doc-update'

    Comment update.

    * sg/setup-doc-update:
      setup.c: fix comment about order of .git directory discovery

:000000 100644 000000000... 611ab4750... A      .clang-format
:100644 100644 320e33c32... 8ce9c6b88... M      .gitattributes
:000000 100644 000000000... 64e605a02... A      .github/CONTRIBUTING.md
[mass snippage]

这是任何人都将为此特定提交始终获得的输出：它首先将提交本身、哈希 IDbdae4af87053490adad2dc9fb184d6d050d46a4c与其第一个父项进行比较8d7fefaac4318ac3155368f475e10f97714ebd47。本次比较中只有一个文件发生了变化，即被setup.c修改。

然后将 commitbdae4af87053490adad2dc9fb184d6d050d46a4c与其第二个 parent进行比较176b2d328ccc305aa2e565c39ad7b0fb24099275。这一次，有许多文件被更改和添加。

第一亲本是在提交该是前分支的前端git merge。第二个提交是作为参数的提交git merge（这是与两个父项的正常合并；如果这是章鱼合并，输出将继续显示针对第三个父项的新提交，依此类推）。

当 Git 执行合并时，它通过以下方式进行：

• 定位合并基础提交（或者在一些罕见的情况下，当有多个合并基础时，构建一个新的提交作为合并基础）；
• 将合并基础提交与当前（HEAD）提交进行比较，获取--ours变更集；
• 将合并基础提交与其他提交进行比较（假设标准的两次提交合并），获得--theirs变更集；和
• 将在这两个变更集中发现的变更组合到基础上。

如果 Git 自己成功地合并了这些，Git 也会继续自己进行新的合并提交。如果没有，它会停止并从用户那里获得帮助。在任何情况下，结果都是一个新的提交，带有一个新的哈希 ID，其父项是--ours提交（旧的 HEAD 提交）和--theirs提交，特别是按照该顺序。

这意味着第一个git log输出部分精确地显示了从--theirs分支中获得的那些尚未存在于--ours分支中的更改（相对于合并基础）。第二个git log输出部分显示了合并提交与它的第二个父项，显示了从--ours分支（与合并基础）获得的、尚未存在于--theirs分支中的更改。

一般来说，第一个这样的部分是有趣的。

您可以--name-status使用git diff或（用于git whatchanged/git log --raw样式输出）git diff-tree并以您喜欢的任何顺序指定合并提交哈希和第一父提交哈希，或任何解析为第一父提交哈希。

¹ Git 有一个git request-pull命令，但是当您单击 Web 服务器上的单击按钮时，这不是您正在使用的命令。

²好吧，不仅仅是学究气。:-)