我想知道如何跟踪Git中的分支是否被推送。基本上,我想从开发分支(而不是仓库)中找到所有分支,并能够检查(在进行一些更改之后)是否推送了任何这些分支。
到目前为止,使用GitPython,here和here中的详细信息,我可以算出以下内容:
import git
from git import Repo
repo = Repo('directory_of_repo') #points to develop not master
paths = set()
for item in repo.head.commit.diff('HEAD@{8 days ago}'):
if item.a_path.find('a_certain_dirctory') != -1:
paths.add(item.a_path)
mg仓库指向develop
时。现在,我不确定是否应该使用HEAD@{8 days ago}
或develop@{8 days ago}
(P.S。天数可以不同)。但是,不确定我应该使用HEAD
还是develop
?在8天的示例中,使用HEAD
时,唯一路径数为86,而使用develop
时,唯一路径数为15。
我真正要寻找的是在develop
分支中查找在特定时间段(例如8天前)中所有已更改的路径(即其中的某些文件已更新)。我应该使用哪个指南(HEAD
或develop
)来跟踪develop
在特定时间段内的更改的任何指导?
我想从主分支中找到所有分支(不是仓库)
这没有意义,因为分支不会从分支分支。
...并能够检查是否推动了这些分支(在进行一些更改之后)。
这个问题可能很有道理,如果有所改写。
这两个的关键是要了解什么是分支,哪些不是。但是在您可以执行此操作之前,您必须意识到,并非每个人都用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。因为提交的哈希ID。这是分支名称的用途。它们在链中保存last提交的哈希ID:H
拥有其父级G
的哈希ID,所以我们可以使用H
查找G
。同时,G
保留其父级F
的哈希ID,因此我们可以使用G
查找F
,依此类推。这些向后的箭头意味着我们只需要让Git为我们记住链中last
...--F--G--H <-- master, branch2, branch3
H
。如果我们git checkout master
然后进行新的提交,它将获得一些大的丑陋的哈希ID,我们将其称为I
。新的提交I
将以其父项指向现有的提交H
:
...--F--G--H
\
I
现在,因为我们选择master
作为到git checkout
的分支,所以Git将更新
namemaster
以保存新提交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:如果他们说嘿,我提交了
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来查找提交I
。
因此,我们的Git已向其发送了提交I
(以及所有较早的提交),现在将向他们发送礼貌的请求:请,如果可以,请更改您的名称master
以指向提交[C0 ]。由他们决定是否服从此礼貌要求。如果他们do服从,他们会将提交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提交,以及我也需要的所有较早的提交,因此我拥有您的所有承诺。然后,在Git中,它为您的每个分支名称创建或更新远程跟踪名称:我的my
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的活跃程度。]