我尝试过许多不同的解决方案，但没有一个对我有效。我得自己想办法。

查找下一个提交

function n() {
    git log --reverse --pretty=%H master | grep -A 1 $(git rev-parse HEAD) | tail -n1 | xargs git checkout
}

查找之前的提交

function p() {
    git checkout HEAD^1
}

Git的所有内部箭头都是单向的，向后指向。因此，没有简单方便的语法来向前推进:这是不可能的。

“逆箭头移动”是可能的，但如果你以前没有见过，那么这样做的方式是令人惊讶的，然后是显而易见的。假设我们有:

A <-B <-C <-D <-E   <-- last
        ^
        |
         \--------- middle

使用middle~2跟随箭头两次从C回到a，那么我们如何从C移动到D呢?答案是:我们从E开始，最后使用名字，向后工作直到中间，记录我们一路访问的点。然后我们只需要在最后一个方向上移动我们想要的距离:向D移动一步，或向E移动两步。

当我们有分支时，这一点尤其重要:

          D--E   <-- feature1
         /
...--B--C   <-- master
         \
          F--G   <-- feature2

哪个提交比C晚一步?没有正确答案，除非你在问题上加上:在特征___的方向上(填空)。

为了枚举C(不包括C)自身和G之间的提交，我们使用:

git rev-list --topo-order --ancestry-path master..feature2

——topo-order确保即使存在复杂的分支和合并，提交也会按照拓扑排序。只有当链不是线性的时候才需要这样做。——ancestry-path约束意味着当我们从feature2向后工作时，我们只列出那些将commit C作为自己祖先之一的提交。也就是说，如果这个图——或者它的相关部分——实际上是这样的:

A--B--C   <-- master
 \     \
  \     F--G--J   <-- feature2
   \         /
    H-------I   <-- feature3

然后对表单feature2进行简单的请求。master按一定顺序枚举提交J、G和I以及F和H。使用——ancestor -path，我们剔除H和I:它们不是C的后代，只是a的后代。使用——topo-order，我们确保实际的枚举顺序是J，然后是G，然后是F。

git rev-list命令在其标准输出中溢出这些哈希id，每行一个。为了向feature2的方向前进一步，我们只需要最后一行。

可以使用add——reverse(这很诱人，也很有用)，这样git rev-list就可以在生成提交后以相反的顺序打印提交。这确实有用，但如果你在这样的管道中使用它:

git rev-list --topo-order --ancestry-path --reverse <id1>...<id2> | head -1

为了获得“id2方向的下一个提交”，并且有一个非常长的提交列表，git rev-list命令在试图写入head时可能会得到一个破裂的管道，因为head已经停止读取其输入并退出。由于shell通常会忽略管道破裂错误，因此这通常是可行的。只是要确保在使用时忽略它们。

在git rev-list命令中添加-n 1和——reverse也很诱人。不要这样做!这使得git rev-list在后退一步后停止，然后反转所访问的(一项)提交列表。所以每次都产生<id2>。

重要的边注

注意带有“菱形”或“苯环”的图形片段:

       I--J
      /    \
...--H      M--...  <-- last
      \    /
       K--L

将一次提交从H“向前”移到最后会得到I或k。对此你无能为力:两次提交都向前一步!如果您从结果的提交开始，并执行另一个步骤，那么您现在已经提交到您开始的路径。

解决这个问题的方法是避免一次只移动一步，从而被锁定在路径依赖链中。相反，如果你计划访问一个完整的祖先路径链，在做其他事情之前，做一个链中所有提交的完整列表:

git rev-list --topo-order --reverse --ancestry-path A..B > /tmp/list-of-commits

然后，访问这个列表中的每个提交，一次一个，您将得到整个链。topo-order将确保你按这个顺序命中i -和j，以及按这个顺序命中k -和l(尽管没有简单的方法来预测你会在K-L对之前还是之后命中I-J对)。

《Hudson》(现在的Jenkins)的创造者Kohsuke Kawaguchi(2013年11月)写道: Kohsuke / git-children-of:

给定一个提交，找到该提交的直接子节点。

#!/bin/bash -e
# given a commit, find immediate children of that commit.
for arg in "$@"; do
  for commit in $(git rev-parse $arg^0); do
    for child in $(git log --format='%H %P' --all | grep -F " $commit" | cut -f1 -d' '); do
      git describe $child
    done
  done
done

正如这个线程所说明的，在一个基于DAG(有向无环图)表示的历史的VCS中，没有“一个父”或“一个子”。

        C1 -> C2 -> C3
      /               \
A -> B                  E -> F
      \               /
        D1 -> D2 ----/

提交的顺序是通过“拓扑顺序”或“日期顺序”来完成的(参见GitPro书籍)。

但是从Git 1.6.0开始，你可以列出提交的子对象。

git rev-list --children
git log --children

注意:对于父提交，你有同样的问题，后缀^ to一个修订参数表示该提交对象的第一个父。^<n>表示<n>的第1个父节点(即rev^等同于rev^1)。

如果你在分支foo上，并发出“git merge bar”，那么foo将是第一个父节点。 例如:第一个父节点是你合并时所在的分支，第二个父节点是你合并的分支上的提交。

我用下面的方法找到了下一个孩子:

git log --reverse --children -n1 HEAD (where 'n' is the number of children to show)

每次提交都存储一个指向其父(在merge(标准)提交的情况下为父)的指针。

因此，没有任何方法可以从父对象指向子提交(如果有的话)。

git rev-list --ancestry-path commit1..commit2

我将commit1设置为当前提交，将commit2设置为当前头部，这将返回在commit1和commit2之间构建路径的所有提交的列表。

输出的最后一行是commit1的子元素(在通往commit2的路径上)。