在我们的工作流程中，没有“直接”提交到主分支。主分支只接收来自拉取请求的合并。我们可以将每次合并看作是添加到master分支的一个新特性。因此，我想得到一个合并到master的列表，作为一种可视化随时间推移添加到产品中的功能块的方法。git或Github API会公开这个查询吗，还是我必须解析原始提交？
yrwegjxp1#
我使用以下脚本：
git log main --first-parent --merges \ --pretty=format:"%h %<(10,trunc)%aN %C(white)%<(15)%ar%Creset %C(red bold)%<(15)%D%Creset %s"
解释每个论点：
main
--first-parent
master
--merges
--pretty-format
%h
%<(10,trunc)%aN
%<(15)%ar
%<(15)%D
%s
结果相当令人满意：
kxkpmulp2#
Git通过**git log**命令公开了这一特性，该命令接受一些开关，这些开关根据父提交的数量过滤呈现的提交。其中一个符合你的要求：
--min-parents=2
下面显示了可从**LibGit2Sharp**项目的vNext分支访问的合并提交（即具有多个父提交）
vNext
$ git log vNext --merges --oneline 090b2de Merge pull request #348 from jamill/credential_callback_fix 0332c35 Merge pull request #260 from ben/great-renaming 3191c1b Merge pull request #239 from ben/libgit2-upgrade-81eecc3 1d544e8 Merge branch 'vNext' 238d259 Merge remote-tracking branch 'origin/master'
通过GitHub API利用相同的输出是可能的，但会稍微复杂一些。这需要从一个分支中检索所有提交，对所有结果分页（为了检索所有提交元数据），同时过滤掉那些只暴露一个父节点的提交。作为起点，下面的url显示了vNext分支的最近30次提交。
eagi6jfj3#
如果你想专注于合并提交，即合并拉取请求的结果，你可以考虑新的Git 2.27（Q2 2020）git log --show-pulls选项。"git log"已学习"--show-pulls"，这有助于路径规范限制历史视图;除了引入真实改变的提交之外，还示出了从侧分支取得整个改变的合并提交，其通常从输出中省略。参见Derrick Stolee ( derrickstolee )（2020年4月10日）。（由Junio C Hamano -- gitster --合并至commit 9af3a7c，2020年4月22日）
git log --show-pulls
git log
--show-pulls
derrickstolee
gitster
revision
签署人：德里克·斯托利默认的文件历史简化为"git log -- <path>"或"git rev-list -- <path>"，重点是提供最小的提交集，这些提交首先贡献了一个更改。修订审核通过只访问合并提交的第一个TREESAME父提交（如果存在），极大地限制了审核提交集。这意味着部分提交图不会被审核，这可能是一个性能优势，但也可以"隐藏"添加了更改但被合并决议忽略的提交。（TREESAME：各个树之间的pathspec没有可辨别的差异; "树与树之间相同"）--full-history选项修改了这一点，它遍历所有提交，如果合并提交有 * any * 不是TREESAME的父提交，则将其报告为"interested"。这往往是重要提交的过度表示，特别是在大多数合并提交都是由拉取请求完成创建的环境中。假设我们有一个提交A，并且在上面创建了一个修改文件的提交B。当我们合并拉取请求时，我们创建一个合并提交M。如果在M和A之间没有其他人改变第一父历史中的文件，则M将不是与其第一父相同的树，而是与B相同的树。因此，简化的历史将是"B"。然而，M将出现在--full-history模式中。然而，假设基于A和M之间的提交C1，C2，...，Cn创建了多个主题T1，T2，...，Tn，如下所示：
git log -- <path>
git rev-list -- <path>
--full-history
A
B
M
C1
C2
Cn
T1
T2
Tn
A----C1----C2--- ... ---Cn----M------P1---P2--- ... ---Pn \ \ \ \ / / / / \ \__.. \ \/ ..__T1 / Tn \ \__.. /\ ..__T2 / \_____________________B \____________________/
如果提交T1，T2，... Tn没有改变文件，那么所有的P1到Pn对于它们的第一个父节点都是TREESAME，但是对于它们的第二个父节点不是TREESAME。这意味着所有这些合并提交都出现在--full-history视图中，其边会立即折叠到较低的历史记录中，而不会引入有趣的单亲提交。引入--simplify-merges选项是为了删除这些额外的合并提交。通过注意到重写的父节点可以从它们的第一个父节点到达，这些边可以被简化掉。最后，这些提交现在看起来像是与其"唯一"父提交TREESAME的单亲提交。因此，它们被删除，这个问题不再会导致问题。但是，这也会导致从历史视图中删除提交M!更糟糕的是，--simplify-merges选项要求在返回单个结果之前遍历整个历史记录。许多Git用户在使用Git的同时还使用Git服务，该服务提供代码存储以及针对目标分支的代码评审工具，通常称为"Pull Requests"或"Merge Requests"。
P1
Pn
--simplify-merges
这为父提交提供了一个有价值的顺序，但也使合并提交稍微有些特殊。用户可能不仅想看到哪些提交修改了文件，还想看到哪些拉取请求将这些提交合并到了他们的分支中。在前面的例子中，这意味着除了单亲提交"C"之外，用户还希望看到合并提交"M".当用户在将特性分支合并到 Backbone.js 之前使用拉取请求合并到特性分支时，他们更可能需要这些合并提交。在某种意义上，用户要求"第一次"合并提交将更改引入到其分支中。只要父顺序一致，就可以使用以下规则处理：如果合并提交与其第一个父项不是TREESAME，但与后续父项是TREESAME，则包括合并提交。这些合并看起来像是在主分支上运行"git pull <topic>"所导致的合并提交。因此，显示这些提交的选项称为"--show-pulls"。
C
git pull <topic>
要测试这些选项，请扩展标准测试示例，使其包含一个与其第一个父项不属于TREESAME的合并提交。令人惊讶的是，该选项尚未出现在示例中，因为它具有指导意义。
特别地，这个扩展展示了文件历史简化的一个常见问题。当用户使用“-Xours“或忽略冲突的一方来解决合并冲突时，他们创建了一个可能不应该是TREESAME的TREESAME边。这会导致用户感到沮丧，并抱怨“我的更改消失了！”根据我的经验，向他们显示--full-history和--simplify-merges的历史记录很快就会发现合并存在问题。如前所述，此选项的计算成本很高。--show-pulls选项 * 可能 * 会更快地显示合并提交（通常标题为“解决冲突”）。当然，这取决于用户是否具有正确的父顺序，当从主题分支使用“git pull master“时，父顺序是向后的。将--show-pulls选件与--simplify-merges组合使用时，需要特别注意一些事项。这需要添加一个新的PULL_MERGE对象标志来存储来自初始TREESAME比较的信息。这有助于避免在后面的过滤器中丢弃这些提交。这在一个测试中涵盖，包括如何简化父对象。由于“struct object“在解析、类型和标志成员之间使用了33位，已经破坏了它的32位对齐，所以我们不要让它变得更糟。PULL_MERGE在revision.c中使用，其值（1u<<15）与commit-graph.c中的REACHABLE相同。REACHABLE标志仅在写入提交图文件时使用，并且使用--show-pulls的修订审核不会在同一进程中发生。将来必须注意确保这种情况仍然存在。更新Documentation/rev-list-options.txt，使其包含有关此选项的重要详细信息。这需要更新历史简化部分中的示例，以演示TREESAME第二个父代的一些问题。请在此处查看完整示例。
-Xours
git pull master
PULL_MERGE
struct object
revision.c
1u<<15
commit-graph.c
REACHABLE
Documentation/rev-list-options.txt
3条答案
按热度按时间yrwegjxp1#
我使用以下脚本：
解释每个论点：
main：您的主分支的名称，可以省略，省略时使用当前分支。--first-parent：跳过合并分支的提交。这将删除某人将master合并到其分支中的条目。--merges：只显示“merge commits”（有多个父提交的提交）。* 如果您想看到直接提交到主分支，请省略此参数。*--pretty-format：应用以下格式：%h：提交短散列;%<(10,trunc)%aN：作者姓名，截断为10个字符;%<(15)%ar：相对提交时间，填充为15个字符;%<(15)%D：标签名称，也填充到15个字符;%s：提交消息的第一行。结果相当令人满意：
kxkpmulp2#
Git通过**git log**命令公开了这一特性，该命令接受一些开关，这些开关根据父提交的数量过滤呈现的提交。
其中一个符合你的要求：
--min-parents=2完全相同。下面显示了可从**LibGit2Sharp**项目的
vNext分支访问的合并提交（即具有多个父提交）更新
通过GitHub API利用相同的输出是可能的，但会稍微复杂一些。
这需要从一个分支中检索所有提交，对所有结果分页（为了检索所有提交元数据），同时过滤掉那些只暴露一个父节点的提交。
作为起点，下面的url显示了
vNext分支的最近30次提交。eagi6jfj3#
如果你想专注于合并提交，即合并拉取请求的结果，你可以考虑新的Git 2.27（Q2 2020）
git log --show-pulls选项。"
git log"已学习"--show-pulls"，这有助于路径规范限制历史视图;除了引入真实改变的提交之外，还示出了从侧分支取得整个改变的合并提交，其通常从输出中省略。参见Derrick Stolee (
derrickstolee)（2020年4月10日）。（由Junio C Hamano --
gitster--合并至commit 9af3a7c，2020年4月22日）revision：- -show-pull添加有用的合并签署人：德里克·斯托利
默认的文件历史简化为"
git log -- <path>"或"git rev-list -- <path>"，重点是提供最小的提交集，这些提交首先贡献了一个更改。修订审核通过只访问合并提交的第一个TREESAME父提交（如果存在），极大地限制了审核提交集。这意味着部分提交图不会被审核，这可能是一个性能优势，但也可以"隐藏"添加了更改但被合并决议忽略的提交。
（TREESAME：各个树之间的pathspec没有可辨别的差异; "树与树之间相同"）
--full-history选项修改了这一点，它遍历所有提交，如果合并提交有 * any * 不是TREESAME的父提交，则将其报告为"interested"。这往往是重要提交的过度表示，特别是在大多数合并提交都是由拉取请求完成创建的环境中。
假设我们有一个提交
A，并且在上面创建了一个修改文件的提交B。当我们合并拉取请求时，我们创建一个合并提交
M。如果在
M和A之间没有其他人改变第一父历史中的文件，则M将不是与其第一父相同的树，而是与B相同的树。因此，简化的历史将是"B"。然而，M将出现在--full-history模式中。然而，假设基于
A和M之间的提交C1，C2，...，Cn创建了多个主题T1，T2，...，Tn，如下所示：如果提交
T1，T2，...Tn没有改变文件，那么所有的P1到Pn对于它们的第一个父节点都是TREESAME，但是对于它们的第二个父节点不是TREESAME。这意味着所有这些合并提交都出现在
--full-history视图中，其边会立即折叠到较低的历史记录中，而不会引入有趣的单亲提交。引入
--simplify-merges选项是为了删除这些额外的合并提交。通过注意到重写的父节点可以从它们的第一个父节点到达，这些边可以被简化掉。
最后，这些提交现在看起来像是与其"唯一"父提交TREESAME的单亲提交。因此，它们被删除，这个问题不再会导致问题。
但是，这也会导致从历史视图中删除提交
M!更糟糕的是，
--simplify-merges选项要求在返回单个结果之前遍历整个历史记录。许多Git用户在使用Git的同时还使用Git服务，该服务提供代码存储以及针对目标分支的代码评审工具，通常称为"Pull Requests"或"Merge Requests"。
这为父提交提供了一个有价值的顺序，但也使合并提交稍微有些特殊。用户可能不仅想看到哪些提交修改了文件，还想看到哪些拉取请求将这些提交合并到了他们的分支中。
在前面的例子中，这意味着除了单亲提交"
C"之外，用户还希望看到合并提交"M".当用户在将特性分支合并到 Backbone.js 之前使用拉取请求合并到特性分支时，他们更可能需要这些合并提交。
在某种意义上，用户要求"第一次"合并提交将更改引入到其分支中。只要父顺序一致，就可以使用以下规则处理：
如果合并提交与其第一个父项不是TREESAME，但与后续父项是TREESAME，则包括合并提交。
这些合并看起来像是在主分支上运行"
git pull <topic>"所导致的合并提交。因此，显示这些提交的选项称为"
--show-pulls"。要测试这些选项，请扩展标准测试示例，使其包含一个与其第一个父项不属于TREESAME的合并提交。令人惊讶的是，该选项尚未出现在示例中，因为它具有指导意义。
特别地，这个扩展展示了文件历史简化的一个常见问题。当用户使用“
-Xours“或忽略冲突的一方来解决合并冲突时，他们创建了一个可能不应该是TREESAME的TREESAME边。这会导致用户感到沮丧，并抱怨“我的更改消失了！”
根据我的经验，向他们显示
--full-history和--simplify-merges的历史记录很快就会发现合并存在问题。如前所述，此选项的计算成本很高。
--show-pulls选项 * 可能 * 会更快地显示合并提交（通常标题为“解决冲突”）。当然，这取决于用户是否具有正确的父顺序，当从主题分支使用“
git pull master“时，父顺序是向后的。将
--show-pulls选件与--simplify-merges组合使用时，需要特别注意一些事项。这需要添加一个新的
PULL_MERGE对象标志来存储来自初始TREESAME比较的信息。这有助于避免在后面的过滤器中丢弃这些提交。这在一个测试中涵盖，包括如何简化父对象。由于“struct object“在解析、类型和标志成员之间使用了33位，已经破坏了它的32位对齐，所以我们不要让它变得更糟。PULL_MERGE在revision.c中使用，其值（1u<<15）与commit-graph.c中的REACHABLE相同。REACHABLE标志仅在写入提交图文件时使用，并且使用
--show-pulls的修订审核不会在同一进程中发生。将来必须注意确保这种情况仍然存在。更新
Documentation/rev-list-options.txt，使其包含有关此选项的重要详细信息。这需要更新历史简化部分中的示例，以演示TREESAME第二个父代的一些问题。请在此处查看完整示例。