显示最初在分支上进行的提交（过滤出合并的提交）

Question

在具有多个分支的git repo中，我已将一个功能分支合并到master，然后从master合并回了feature分支。现在如何使用git log仅查看功能分支上的那些提交？我需要过滤掉对其他分支所做的注释，即使它们已合并回到此功能分支中。

$ git status
On branch some_feature

$ git checkout master
$ git merge some_feature
$ git checkout some_feature
$ git merge master

$ # Lots of coding and days gone by

$ git log --some_magic_here

如果有问题，我要在其上运行git log的计算机与用于对该功能进行编码的计算机不同。我需要此功能才能对另一位开发人员的工作进行代码审查。筛选依据author=SomeDev无济于事，因为我正在查看一个特定的功能分支。

Answer 1

TL; DR：您需要--first-parent（请参阅git rev-list文档）和其他一些选择标准。

Git不会跟踪“实际上在哪个分支上进行了提交”。例如，假设您在分支机构上，B并且执行此操作：

$ git checkout --detach B
[message about "detached head"]
[edit some file here, and git add result]
$ git commit -m message
$ git branch -f B HEAD
$ git checkout B

B即使该提交是在完全不在分支上时进行的，这也会向分支的尖端添加新的提交。或者，假设有两个分支，B1并且两个分支B2都指向commit C7：

... <- C5 <- C6 <- C7   <-- B1, B2

如果您进行C8父提交的新提交C7，然后使分支B2指向C8该提交，则该提交现在在分支上B2。如果你取得了新的承诺，而在分支B1随后B1也指出C8，但如果你再使用git reset移动B1到点回C7，它是不再可能告诉¹，该提交的最初提出B1，而不是B2。

综上所述，如果在合并分支时保持良好的一致性，则可以在提交图上执行图遍历，查找特定合并之间的提交，然后遍历一个特定的父链，以检测提交可能完成的分支-上。例如，与feature和master描述，假设提交是在始终如一地feature，然后feature定期合并到master同--no-ff以确保每个合并提交上master是一个真正的合并提交，而不是仅仅是一个快进。然后，图形模式将如下所示：

... --X--*------*-o---o-----*--*   <-- master
       \       /   \       /  /
        A--B--C--D--E--F--G--H     <-- feature

（其中“时间”随着向右移动而增加，并且*节点是在branch上进行的合并提交master，而o节点表示在master上的其他提交）。

在这种情况下，您可以找到（可能）进行的提交，方法是feature从feature（commit H）的尖端开始，并且仅遍历第一个父级提交（这些A通过）H，然后通过仅遵循第一个父级提交来丢弃可找到的提交master。第二个条件消除了X上面标记的提交（以及所有先前的提交）。（请注意，对于合并提交E，其第一个父级是D，其第二个父级是其o上方左侧的提交master。对于所有合并master，，第一个父级位于同一行，第二个父级位于下面并在左侧feature）

这是否足够取决于您（和其他人）在提交过程中的纪律性。如果master具有自己的内部分支并合并，则可能会有一个更像这样的图：

... --X---Y---*-----*-o---o---------*--*   <-- master
       \   \ /     /   \           /  /
        \   Z     /     \         /  /
         \       /       \       /  /
          A--B--C--D------E--F--G--H       <-- feature

现在，您不能那么容易地使用第一个/非第一个父级测试，因为commit Y或Z必定是合并的第二个父级master，但是请注意，如果没有第一个遍历，Z就无法通过它来访问，这是“直接合并” on”，其第二个父提交为on 。featureEfeaturemaster

换句话说，我在分支上使用了一个特有的短语“直接在分支上”，以识别可找到的提交，方法是从分支的尖端开始，然后仅通过第一个父级向后工作。因为feature这些（仍然）A到H，再加上不幸的是X及其（第一）父母。

该git rev-list命令是git的非常重要的命令之一，它是git的大姐姐版本，git rev-parse也是非常重要的命令。它带有一个标志，专门用于实现“直接打开”概念，即--first-parent。rev-list命令在提交图的某些部分中遍历²：您告诉它一些从其开始的提交，它发现了提交的父母，那些父母的父母及其父母，依此类推。如果指定，--first-parent则仅查找每个提交的第一个父级。（这显然只影响合并提交，因为根据定义，一个非合并提交最多具有一个父提交。）

在您的特定情况下，你也说要消除合并到你的feature分支，即合并提交直接上feature。为此，只需使用告诉rev-list从其输出中排除合并提交--no-merges。

消除提交X和更早的提交会有点困难，但事实证明，只要知道哪个分支包含要排除的提交（如），就不那么困难了X。该--not参数（包括几种可供选择的拼写）告诉REV-名单什么承诺排除。所以：

git rev-list --first-parent feature --not master --no-merges

标识“直接在”功能上的提交列表（A通过H），而不是直接在master（X及更早版本）上的提交列表，然后仅列出那些不属于合并的列表（从而消除commit E）。

您可能希望进一步减少这种情况，例如，通过使用提交时间戳记（--since和--until）。您可能会（也可能不会）想要更改修订的列出--topo-order顺序，例如，可能使用了按图表顺序而不是日期顺序进行排列。

放在一起 git log

对您来说幸运的是，可以使用您的修订说明符git log有效地进行调用git rev-list。因此，您不必给git rev-list先使用，然后以某种方式将结果反馈给git log，而只需将相同的说明符赋予即可git log。实际上，在确定所需的限制器时（例如--since和--until），git log使用起来很容易，因为一大堆原始SHA-1对人类不是很有用。

¹实际上，保留了分支运动历史的reflog确实可以告诉您，但只能在一台本地计算机上进行；问题是，这必须在其他系统上完成，而无法使用reflog。无论如何，reflog条目将在一段时间后过期，对于此处感兴趣的条目，默认情况下为90天。

²当然，除非您使用--no-walk。