（这是对一个重复问题的回答。我做了一些简单的编辑来清理它。）
Git的所有内部箭头都是单向的，向后指向。因此，没有前进的简短便捷语法：这是不可能的。
这是可能的“反箭头移动”，但做到这一点是令人惊讶的方式，如果你以前没有见过它，然后明显之后。假设我们有：
A <-B <-C <-D <-E <-- last
^
|
\--------- middle
使用middle~2跟随箭头两次，从C返回到A。那么我们如何从C转到D？答案是：我们从E使用名称开始last，然后向后工作直到到达middle，记录沿途访问的点。然后，我们只要将据我们希望的方向last：移动一步D，或两个E。
当我们有分支机构时，这尤其重要：
D--E <-- feature1
/
...--B--C <-- master
\
F--G <-- feature2
下一步是哪一个提交C？在您添加到问题之前，没有正确的答案：朝Feature___方向（填写空白）。
要枚举C（不包括C）本身与，例如之间的提交G，我们使用：
git rev-list --topo-order --ancestry-path master..feature2
这样--topo-order可以确保即使存在复杂的分支和合并，这些提交也可以按照拓扑排序的顺序出现。仅当链不是线性时才需要。该--ancestry-path约束意味着，当我们从进行反向操作时feature2，我们仅列出已将提交C作为自己祖先之一的提交。也就是说，如果图形（或无论如何相关图）实际上看起来像这样：
A--B--C <-- master
\ \
\ F--G--J <-- feature2
\ /
H-------I <-- feature3
表单的简单请求feature2..master枚举了commits J，G和I，F并且H按某种顺序。随着--ancestry-path我们的淘汰H和I：他们不是的后代C，只是的后代A。随着--topo-order我们确保实际的枚举顺序J，然后G，然后F。
该git rev-list命令将这些哈希ID溢出到其标准输出中，每行一个。要向方向前feature2进一步，我们只需要最后一行。
这是可能的（和诱人的和有用的）添加--reverse，使git rev-list打印出提交相反的顺序生成它们之后。确实可以，但是如果您在这样的管道中使用它：
git rev-list --topo-order --ancestry-path --reverse <id1>...<id2> | head -1
为了仅获取“沿id2方向的下一个提交”，并且提交列表非常长，该git rev-list命令在尝试写入时将得到一个中断的管道，该管道head已停止读取其输入并退出。由于外壳通常会忽略断线错误，因此大多数情况下都可以使用。只要确保它们在您的用法中被忽略即可。
与一起添加-n 1到git rev-list命令中也很诱人--reverse。别做！这使得git rev-list停车后步行一步回来，然后反向访问提交的（一个条目）列表。因此，这<id2>每次都会产生。
重要注意事项
请注意，带有“钻石”或“苯环”图片段：
I--J
/ \
...--H M--... <-- last
\ /
K--L
移动一个承诺“前进”从H朝last将让你无论是 I 或 K。您对此无能为力：两次提交都向前迈了一步！然后，如果您从生成的提交开始并进行下一步，那么您现在将遵循开始的任何路径。
解决方法是避免一次只移动一个步骤，而不会陷入与路径相关的链中。相反，如果您打算访问整个祖先路径链，则在进行其他操作之前，请完整列出链中所有提交的列表：
git rev-list --topo-order --reverse --ancestry-path A..B > /tmp/list-of-commits
然后，一次访问此列表中的每个提交，您将获得整个链。该--topo-order会确保你打I-和- J的顺序，和K-和- L的顺序（虽然有没有简单的方法来预测你是否会在KL对之前或之后做IJ对）。