git - 显示最初在分支上进行的提交(过滤出 merge 的提交)

Question

在一个有多个分支的git repo中，我将一个功能分支合并到master中，并从master合并回功能分支中。现在如何使用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的机器与用来编码该特性的机器不同。我需要这个特性来对另一个开发人员的工作执行代码检查。filter by author=SomeDev没有帮助，因为我正在查看一个特定的功能分支。

Answer 1

tl；dr：您需要--first-parent（请参见git rev-list documentation）和一些其他选择标准。
git不跟踪“提交是在哪个分支上进行的”。例如，假设您在branchB上，并执行以下操作：

$ 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都指向commit B2：

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

如果生成父级为 C7的新提交，则使branch C8指向 C7，则该提交现在位于branch B2上。如果在branch C8上执行新的提交，则 B2也指向 B1，但如果随后使用 B1移动 C8以指向 git reset，则无法再告诉1提交最初是在 B1上执行的，而不是在 C7上执行的。
综上所述，如果合并分支时保持良好的一致性，则可以对提交图执行图遍历，在特定合并之间查找提交，然后通过一个特定的父链来检测提交可能是在哪个分支上完成的。例如，如前所述，使用 B1和 B2时，假设提交始终在 feature上进行，然后将 master定期合并到 feature和 feature中，以确保 master上的每个合并提交都是真正的合并提交，而不仅仅是快进提交。然后图形模式将如下所示：

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

（其中，“时间”随着一个节点向右移动而增加， --no-ff节点是在branch master上进行的合并提交， *节点表示master上的其他提交）。
在本例中，您可以通过从 master（commit o）的提示开始并仅遍历第一个父提交（这些提交是 feature到 feature）来查找（可能）在 H上进行的提交，然后通过仅跟踪 A上的第一个父提交来丢弃可查找的提交。第二个条件消除了上面标记为 H的提交（以及之前的任何提交）。（注意，在merge commit master的情况下，第一个父级是 X，第二个父级是 E上的 Dcommit，位于 o左侧。对于 master上的所有合并，第一个父级位于同一行，第二个父级位于 master上的下方和左侧）
这是否足够取决于您（和其他人）在提交过程中的纪律性。如果 feature有自己的内部分支和合并，则可能有一个更像这样的图形：

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

现在，您不能简单地使用第一个/不是第一个父测试，因为commit master或 Y必须是 Z上合并的第二个父测试，但请注意，如果不首先遍历 master，则无法从 Z访问 feature，这是一个“直接打开” E的合并提交，其第二个父提交处于 feature上。
换言之，我使用稍微有点奇怪的短语“直接在”一个分支上标识提交，这些提交可以从分支尖端开始，然后只通过第一个父级反向工作。对于 master来说，它们（仍然）是 feature到 A之间的，不幸的是，加上 H和它的（第一）双亲。
X命令是git的一个非常中心的命令它是 git rev-list的一个姐姐版本，也是非常中心的，它有一个标志，专门实现这个“直接打开”的概念，即 git rev-parse。rev list命令遍历commit图的某些部分：告诉它从某个commit开始，它会找到commit的父级、父级和父级，依此类推。如果指定 --first-parent，则仅查找每个提交的第一个父级。（这显然只影响合并提交，因为根据定义，非合并提交最多有一个父提交。）
在您的特定情况下，您还说希望消除到 --first-parent分支的合并，即直接在 feature上的合并提交。为此，只需告诉rev list从其输出中排除合并提交，并使用 feature。
消除commit --no-merges和更早的版本有点困难，但事实证明，如果您知道要排除的哪个分支包含像 X这样的提交，那么就不是那么困难了。 X参数（包括几个可选的拼写）告诉rev list要排除的提交。所以：

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

标识提交“直接打开”功能（ --not到 A）但不直接打开 H（ master和更早版本）的列表，然后仅列出未合并的那些（从而消除提交 X）。
您可能希望进一步减少这一点，例如，可以使用提交时间戳（ E和 --since）。您可能（或可能不想）也要更改修订的列出顺序，例如，可以使用 --until将它们按图形顺序而不是日期顺序排列。
将此与 --topo-order
幸运的是， git log使用您的修订说明符有效地调用了 git log。因此，不必先使用 git rev-list，然后以某种方式将结果输入 git rev-list，只需将这些相同的说明符赋给 git log。事实上，当你想知道你想要什么限制器（比如 git log和 --since）的时候， --until更容易操作，因为一大堆原始的sha-1对人类不是很有用。
1实际上，保留分支运动历史的重新登录确实使您能够分辨，但只能在一台本地计算机上；问题是，这必须在重新登录不可用的另一个系统上完成。在任何情况下，重新登录条目将在一段时间后过期，此处感兴趣的条目默认为90天。
2当然，除非您使用 git log。