我可以使用git status告诉我，我是在遥控器前方还是后方：
git status
On branch master
Your branch is ahead of 'bean/master' by 1 commit.
(use "git push" to publish your local commits)
nothing to commit, working tree clean
哪种方法可以解析：
needs_push = "Your branch is ahead" in std.out
needs_pull = "Your branch is behind" in std.out
但是，当使用多个遥控器时，由于git status仅显示一个遥控器（上例中的bean）的结果，并且没有参数来选择遥控器，因此事情会失败。
我有什么方法可以指定遥控器来显示详细信息吗？ 即给定两个遥控器，我的本地存储库/分支是否需要推送和/或拉动，如果是，那么？需要拉动＆＃34;我的意思是遥控器包含我没有得到的提交，而且需要推送＆＃34;我的意思是我已经得到了遥控器没有得到的提交。 （即假设没有任何深奥的线性工作流程。）
如果我可以使用URL而不是更好的名称，但据我所知，git只能在调用git remote update后才能描述遥控器。
答案 0 :(得分：2)
可能更容易（取决于你想要达到的目标）：
$ git rev-list --count <branch-name>..<remote>/<remote-branch-name> 将输出第一个分支在远程分支后面的提交数
$ git rev-list --count <remote>/<remote-branch-name>..<branch-name> 将输出第一个分支在远程分支之前的提交数
使用此命令，您可以列出您可能想知道的各种事物。但您首先需要了解gitrevisions。
$ git rev-list --count <some git revision specification>
根据您对这些信息的具体要求，以下内容可能会派上用场：
$ git branch -u <upstream> # short for --set-upsteam-to=<upstream>
设置当前分支的上游
$ git status --porcelain=v2 --branch获取一个非常容易解析的输出，其中包含有关上游关系的信息
输出结果如下所示：
# branch.oid <hash>
# branch.head example-branch
# branch.upstream origin/example-branch-developer-1
# branch.ab +0 -1
最后一行对您来说最有趣，具有以下格式：
# branch.ab +<ahead> -<behind>
答案 1 :(得分：0)
如果我可以使用URL而不是更好的名称，但据我所知，git只能在调用
git remote update后才能描述遥控器。
这是正确的，如果有点不精确的话。发生了什么＆＃34;引擎盖下＆＃34;这是完成后git fetch - git remote update只是或多或少地运行git fetch到各种遥控器，您可以从git fetch本身执行此操作，因此请使用你喜欢的命令，他们基本上在这里做同样的事情 - 你的 Git现在在你的存储库中有他们的 Git所拥有的每一个提交;和您的 Git已更新您的远程跟踪分支名称，例如origin/master和bean/master以及您拥有的其他任何遥控器。
因此，既然你拥有他们拥有的以及更多（如果还有其他任何东西），你现在可以弄清楚你所指定的任何分支名称是否指向：
（最后一种情况不太可能，但应该提到完整性。）
这些提交链是由提交图或DAG形成的：
A <-B <-C <-- master
代表一个非常简单的存储库，只有三次提交。我们说名称 master＆＃34;指向＆＃34;提交C，因为master包含大的丑陋哈希ID，即＆＃34;真名称＆＃34;提交C。同时，提交C包含提交B的哈希ID，因此C指向B;同样地，B指向A。 B是C的父母，A是B的父母。
由于A是第一次提交，因此它没有父提交ID;所以它没有。这使它成为 root commit ，它无处可指，这意味着git log可以停止打印。我们或git log - 将以名称master开头并查看提交C，然后按C箭头返回B并查看B。然后它会按照向后箭头的A并查看A，现在它已经完成了要完成的事情。
当您git fetch以D作为其父级的新提交C时，我们会得到稍微复杂的图片：
A--B--C <-- master
\
D <-- bean/master
从这张图中可以很容易地看出bean/master是＆＃34;提前一个提交＆＃34; master。但在内部，所有Git箭头都向后工作，所以实际上，Git必须从bean/master开始，然后返回，当它找到C时master }，当我们知道master落后于bean/master时。
作为AnimiVulpis answered（已投票），您可以使用git rev-list为您提供--count 计数提交。通常它只列出提交哈希值。它就像git log：它从您告诉它开始的提交开始，并遵循内部＆＃34;箭头＆＃34;从一个提交到另一个提交。如果你给它一个停止点，当它到达作为停止点的提交时停止或者 - 这个部分有点棘手 - 可以从停止点到达
让我们绘制一个稍微复杂的图片，您已经在master上做了一个新的提交 - 我们会调用此E - 然后引入{ {1}}从D bean指向它：
bean/master现在 E <-- master
/
A--B--C
\
D <-- bean/master
是master之前的一次提交，而bean/master是bean/master之前的一次提交，同时提交。这是因为如果我们从master开始并向后工作，我们会发现一个从master开始向后工作无法达到的提交。如果我们从另一个方向开始也是如此。
因此，我们需要两个 bean/master命令。我们会使用git rev-list又称master ^bean/master运行一个：从bean/master..master开始，到达提交master时停止，因为它可以从C到达。这会在bean/master上对提交E进行计数，然后停止。另一方面，我们将使用master又名bean/master ^master：从master..bean/master开始，到达提交bean/master时停止，因为它可以从C到达。
这个可达性概念是使Git工作的关键图形理论位之一。可视化它的一个好方法是想象暂时为每个提交着色，就像用荧光笔一样：我们将一些提交的颜色设置为红色，如＃34;停止＆＃34;如果我们同时做两种颜色＆＃34;并且＃34;那么其他人就会变成绿色，如果＆＃34;去＆＃34;，并且红色倾向于覆盖绿色。 master表示法表示从X ^Y开始使用绿色，从X 开始使用红色。 Y符号只是同一事物的简写。
事实证明，Git有一个特殊符号Y..X（三个点而不是两个），表示对称差异：如果只能从到达，颜色会提交绿色一个起点，但如果两者都可以，则为红色。在此图表中，X...Y会选择提交bean/master...master - 可以从E但不能master - 和提交bean/master，但是拒绝提交D及更早。
在您发现C也有git rev-list选项之前，这似乎并不一定非常有用。当使用具有对称差异三点语法的此选项时，Git将注意哪些提交来自＆＃34;左侧名称＆＃34; （--left-right），来自＆＃34;正确的名称＆＃34; （bean/master）。通常，当master吐出提交哈希ID时，它会使用git rev-list和<来标记这些内容。但是如果你添加>，Git就像往常一样计算它们，然后输出两个数字：
--count左边的数字是可以从git rev-list --count bean/master...master
但不能从bean/master到达的提交数，右边的数字是可以从master到达但不能从master到达的提交数量bean/master。
And-aha !-这些正是git status打印的数量＆＃34;背后＆＃34;并且＆＃34;未来＆＃34;。 （如果您愿意，可以交换名称以其他顺序获取它们。）
如果您使用不相关的存储库或git checkout --orphan，您可以在其中创建一个包含不相交的子图的存储库：
A--B--C <-- master
D--E <-- unrelated/master
在这种情况下，对称差异符号将列出或计算两个分支上的所有提交，因为它所做的只是列表或计数提交可以从任一名称访问，但不能从两个名称访问。由于父链永远不会聚集在一起，因此可以从两者中获得 no 提交。
如果您确实需要，可以检测到这种情况 - 当它发生时，两个名称之间没有合并基础 - 但通常不应该首先发生。请注意，具有多个根不是保证，因为我们可以故意合并不相关的历史：
A--B
\
E--F <-- branch
/
C--D
我们甚至可以在合并后拥有一个分支：
A--B G <-- br1
\ /
E--F
/ \
C--D H--I <-- br2
但是这些分支做有一个合并基础提交（它的提交F，从图中可以看出这一点。）