如果将git分支推送到远程并在合并之前删除它,它是否仍然是存储库历史记录的一部分?

时间:2017-05-11 16:08:26

标签: git

已创建分支并将其推送到远程,并且已为其打开合并请求。在某些时候,我们决定做出足够重大的改变,只需从一个新分支开始,这可能是最简单的方法。

当从远程数据库中删除原始分支时,它的任何历史记录是否会在远程存储库中停留,或者它(以及与之关联的任何提交)是否已从远程存储库中完全删除?

更简洁地说,如果我删除了一个远程分支而没有将它合并到主分支并且有人做了回购的git克隆,他们最终会下载关于那个现已删除的分支的任何类型的历史信息,或者通过' clean'克隆w.r.t.这个分支?

2 个答案:

答案 0 :(得分:3)

删除远程分支不会删除提交;它们最终可能会被git gc运行清理干净。如果远程服务器位于本地共享驱动器或类似的东西上,那么如果/何时在其上运行gc,则由您决定;即便如此,如果 nothing (包括reflogs)可以达到该提交,gc运行只能删除提交。如果它包含在服务器(类似TFS)或托管(通过github或类似),那么它取决于服务器或托管服务公开的选项,是否/如何运行{{1 }}

因此,提交可能会暂时停留一段时间,并且知道他们正在寻找什么的人可以访问。

但你特别询问有人克隆/拉扯。在pull或clone上发送的包不包含某些ref无法访问的内容。在这种情况下,即使有一个reflog条目,它也不相关。如果删除远程分支,并且没有任何提交被标记,合并或在其上创建了另一个分支,则提交不应包含在拉动或关闭操作中。

答案 1 :(得分:3)

  

更简洁地说,如果我删除了一个远程分支而没有将它合并到主分支并且有人做了回购的git克隆,他们最终会下载关于那个现已删除的分支的任何类型的历史信息,或者通过'clean'wrt克隆这个分支?

确实很难说。原则上,克隆存储库的人应该不能从他们克隆的任何引用名称中获取任何无法访问的对象。实际上,某些服务器端快捷方式可能会导致“数据泄露”。

为了使示例完全具体,请考虑您正在调用origin的某个远程主机上的存储库 R R 本身只有一个master分支,提交哈希1234567...。然后你做了git push origin newbranch,在 R 中添加了一些对象(包括至少一个新的提交),并在origin获取Git以添加新的分支newbranch哈希ID fedcba9...。然后你说:“哎呀,不,我们不希望这样”并且git push origin :newbranch删除名称 newbranch

如果服务器上没有reflog,则提交fedcba9...及其对象(以及任何早期无法访问的提交)现在有资格进行垃圾回收,如Ryan noted in a comment。如果这些所有被垃圾收集,它们真的消失了,无法通过任何正常手段观察到。 1

如果没有,他们仍然在 R ,他们只是没有名称,可以通过它们找到它们。或者,如果提交散列或散列保存在reflog中,它们确实有名称,但这些是reflog名称,而不是常规引用。 git clonegit fetch进程无法获取reflog,因此无法“查看”哈希ID,但在reflog条目到期之前,提交fedcba9...并且相关对象尚不符合垃圾回收的条件

现在我们继续git clone进程。当你跑:

git clone <options> <url>

你让你的Git在给定的URL上调用另一个Git。然后,您的Git从该Git请求所有正常(非reflog)引用的列​​表。对于repo R ,那只是refs/heads/master = 1234567...,因为refs/heads/newbranch已经消失。然后,您的Git会请求一些(如果--depth浅层克隆)或可以从部分或全部这些名称(例如master)访问所有对象。由于来自fedcba9...的{​​{1}}永远不会 ,因此他们的Git 应该不发送它。

但是,可以选择在服务器上进行快捷方式。服务器具有这些“pack”文件,其中包含不是松散对象的每个对象。如果只有一个打包文件包含所有内容,并且没有松散的对象......那么:如果服务器只能向您发送一个包含所有的“打包”文件,为什么会这样可以节省服务器否则,他们将花费大量时间和精力来构建一个新的自定义包文件,其中只包含您想要的对象。如果您要求所有参考,您必须所有。只有一包,没有松散的物体;那是一切。没有理由花费所有时间和精力来构建自定义包,对吗? : - )

所以,如果服务器执行此操作, if if 一个大包文件碰巧有提交master及其相关对象,然后(并且只有那时)你会得到一个包含fedcba9...及其相关对象的包文件。然后由你的Git重新打包并丢弃不需要的对象。

这在实践中是否会发生?我过去见过这样的事情,但我不知道它究竟发生在什么情况下。不同版本的Git在其中有不同的代码。 GitHub等大量使用频繁的服务器(还有其他服务器)可能在他们的Git实现中有定制的黑客攻击(其中很多,例如包位图,随着时间的推移已经进入常规Git)。

简短版本是,如果任何已删除的数据项敏感(密码等),您应该认为它们已被入侵。如果您只是担心可能会下载额外的数据,那么,您无法真正控制它:希望 R 的主机不会以这种方式缩短打包速度,或者已经完成了适当的垃圾收集。

1 换句话说,文件系统备份,快照或者例如NSA级数据恢复工具仍然可以找到它们,但Git不会。