我对Git和Python都是陌生的。我找到了一个名为GitPython（https://gitpython.readthedocs.io/en/stable/tutorial.html#the-index-object）的Python程序包，并对其进行了检查。我不知道如何跟踪分支是否被推送。基本上，我想从master分支（不是repo）中找到所有分支，并能够检查（在进行一些更改之后）是否推送了这些分支中的任何一个。该文档没有讨论我在寻找什么。知道怎么做吗？
我想从主分支中找到所有分支（不是仓库）
这没有意义，因为分支不会从分支分支。
...并能够检查是否推动了这些分支（在进行一些更改之后）。
这个问题可能很有道理，如果有所改写。
这两个的关键是要了解什么是分支，哪些不是。但是在您可以执行此操作之前，您必须意识到，并非每个人都用branch表示相同的意思。实际上，某人可以在同一句子中多次说出
在任何存储库中，真正重要的是
not
分支。 commits很重要。分支就是您find提交的方式。在这种特定情况下，单词branch的意思是branch name，例如master或develop。这些名称特定于此一个存储库。此存储库的副本（在其他某些Git中，也许在其他计算机上或在某些云服务器上或任何其他计算机上）具有其自身分支名称，独立于您自己。[当您使用git fetch或git push将两个Git存储库相互连接时，一个Git将提交发送到另一个Git，而另一个Git接收提交。接收方Git可以看到部分或全部发送方Git的名称（分支名称，标签名称和其他名称），但真正重要的是提交。但是，在发送或接收了一些提交后，我们就遇到了查找
提交的问题。每个提交都有唯一的哈希ID。该哈希ID大而丑陋，人类无法记住。幸运的是，每个提交都记住一组previous
提交哈希ID，通常是一组。 Git将此称为parent提交。子提交会记住其父级的哈希ID。当您进行新提交时，Git会为新提交分配一个新的唯一哈希ID，并将您现在使用的提交的哈希ID用作新的子提交（作为孩子的父提交）。 （现在您正在使用子提交。）当然，该父提交本身可能是先前某个提交的孩子。因此，父级会记住its父级（刚创建的孩子的祖父母），而that
提交会记住its父级，依此类推。结果是一个很长的，指向后的链，其中last提交可能是最有趣的：... <-F <-G <-H
这里H代表last提交的哈希ID。因为
H拥有其父级G的哈希ID，所以我们可以使用H查找G。同时，G保留其父级F的哈希ID，因此我们可以使用G查找F，依此类推。这些向后的箭头意味着我们只需要让Git为我们记住链中last
提交的哈希ID。这是分支名称的用途。它们在链中保存last提交的哈希ID：...--F--G--H <-- master, branch2, branch3
H。如果我们git checkout master然后进行新的提交，它将获得一些大的丑陋的哈希ID，我们将其称为I。新的提交I将以其父项指向现有的提交H：
...--F--G--H \ I
现在，因为我们选择master作为到git checkout的分支，所以Git将更新
name附加的master以保存新提交I的哈希ID：
...--F--G--H <-- branch2, branch3 \ I <-- master (HEAD)
(HEAD)是我们（和Git）在进行新提交时知道要移动哪个分支名称的方式。其他两个分支名称-
branch2和branch3-未更改。如果我们git checkout branch3，我们得到：...--F--G--H <-- branch2, branch3 (HEAD)
\
I <-- master
如果现在进行新的提交，则会得到：
J <-- branch3 (HEAD) / ...--F--G--H <-- branch2 \ I <-- master几乎就是它的全部：分支名称只是指向提交的指针。
如果我们的Git通过互联网电话呼叫其他Git，我们的Git可以告诉他们的Git：因此，他们只需要首先交换哈希ID：如果需要的话，提交（所有文件的快照）可以在以后进行（并且可以压缩为其他Git真正需要的），并且它是[[just这里重要的哈希ID。[一旦我们给了他们嘿，我已经提交了
如果他们说I，你知道吗？no] >，我们的Git可以给他们提交
I。 Universe中的所有Git都同意提交I获得提交I的哈希ID，没有其他提交获得该哈希ID。
I-如果需要的话，也给了H，如果需要的话也给了G-他们可能会看起来像这样：...--F <-- master
\
G--H--I
即，they
的名称为master，指向其现有提交F，该哈希与我们现有的F具有相同的哈希ID，因此是具有相同文件的相同提交。现在，它们也具有G-H-I，其中I指向H，H指向G，G指向F。但是他们没有name来查找提交由他们决定是否服从此礼貌要求。如果他们do服从，他们会将提交I。因此，我们的Git已向其发送了提交
I（以及所有较早的提交），现在将向他们发送礼貌的请求：请，如果可以，请更改您的名称master以指向提交[C0 ]。
I的原始哈希ID（无论是什么）填充到their名称I中。所以：
按照措辞，这仍然不是明智的选择。但是我们
can要做的是将它们称为另一个Git，向他们询问，我们不同步，我们不知道。我们只会知道我们是否同步。这可能是您在这里想要的问题。 （如果您想确切地知道我们如何out同步，如果我们不同步，这是一个更困难的问题。）因此，要回答这个新的不同问题，我们应该调用他们的Git，让他们列出分支名称并包含原始哈希ID，然后将其与their
名称master中的哈希ID，并将其与our
名称中的hash ID进行比较。master。这些是相同的哈希ID吗？如果是这样，我们是同步的。如果不是，我们不是。确切地[[如何
我们
分支名称并包含原始哈希ID进行比较。他们会匹配还是不匹配；也许我们会有他们没有的分支名称，反之亦然。但是，在进行任何此操作之前，请考虑master的最后一个功能（无论如何，都是由Git实现的：这可能会或可能不在您的Python库中，具体取决于它模仿Git的精确度或是否直接使用Git） 。我可以使用git fetch将my Git连接到您的
Git：git fetch当我这样做时，您的
Git告诉my Git它的所有分支和标记名称。然后，我的Git让我选择我喜欢的名称（默认是我喜欢所有的名称），它会从您的每个分支名称中获取last提交，以及我也需要的所有较早的提交，因此我拥有您的所有承诺。然后，在：我的my
Git中，它为您的每个分支名称创建或更新远程跟踪名称
git remote add my-name-for-you <url-for-your-git>
git fetch my-name-for-you
拥有您的my-name-for-you/master拥有的哈希ID；我的master拥有您的my-name-for-you/develop拥有的哈希ID；...依此类推，对于您拥有的每个分支名称。develop。我的Git调用您的Git，更新我的名字记忆，并获取所有提交。给予
git fetch my-name-for-you，我将向您发送提交，并要求您的Git设置您的git push my-name-for-you master。您的Git要么听从，要么说不，并告诉我一些为什么它拒绝的信息。如果您的Git服从，我的Git将更新我的master，以记住您的my-name-for-you/master现在存储的是我刚发送给您的哈希ID。因此，通常，您只需检查自己的master名称的哈希ID，而不是
connecting to
其他Git。名称origin/*是默认遥控器的默认名称，该名称是在您通过克隆其他Git存储库首次创建Git存储库时创建的。如有必要，可以在检查origin名称之前运行git fetch origin。（（出于某些特殊工具的目的，有时使用origin/*而不是git ls-remote会更好。这将获得名称和哈希ID，这是实际git fetch的第一步，但只需打印它们即可停下来，而不是继续进行git fetch的其余工作，不利的一面是您最终可能需要git fetch，但不利的一面是您获得了目前准确的图像，而没有等待git fetch工作。此时间可能不会很长，具体取决于另一个Git的活跃程度。]