Git:什么是悬挂提交/ blob,它们来自哪里? [英] Git: what is a dangling commit/blob and where do they come from?

查看:650
本文介绍了Git:什么是悬挂提交/ blob,它们来自哪里?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在寻找关于悬挂提交和放大器的基本信息。 blob。



我的回购看起来很好。但是我第一次运行 git fsck 来看看它做了什么,并且我有一长串'晃来晃去的斑点'和一个'悬挂提交'。



这些东西是什么?哪儿来的呢?他们是否指出我的回购状态有什么不同(好的或不好的)?

解决方案

在使用git存储库,你可能会退出操作,并采取其他措施,导致中介blob,甚至git为你做的一些事情,以帮助避免信息丢失。



最终(有条件地,根据 git gc手册页)它将执行垃圾回收并清理这些东西。你也可以通过调用垃圾收集过程 git gc



来强制执行。有关这方面的更多信息,请参阅在git-scm网站上维护和数据恢复



默认情况下,GC的手动运行将在运行此安全网命令前的两周左右。实际上,偶尔运行GC有助于确保您的git存储库的高性能使用。然而,像任何事情一样,在破坏那些对你很重要的事情之前,你应该明白它在做什么。


I'm looking for the basic info on dangling commits & blobs.

My repo seems fine. But I ran git fsck for the first time to see what it did and I have a long list of 'dangling blobs' and a single 'dangling commit'.

What are these things? Where did they come from? Do they indicate anything unusual (good or bad) about the state of my repo?

解决方案

During the course of working with your git repository, you may end up backing out of operations, and making other moves that cause intermediary blobs, and even some things that git does for you to help avoid loss of information.

Eventually (conditionally, according to the git gc man page) it will perform garbage collection and clean these things up. You can also force it by invoking the garbage collection process, git gc.

For more information about this, see Maintenance and Data Recover on the git-scm site.

A manual run of GC will by default leave 2 weeks prior to the runtime of this command of a safety net. It is in fact encouraged to run the GC occasionally to help ensure performant use of your git repository. Like anything, though, you should understand what it is doing before destroying those things that may be important to you.

这篇关于Git:什么是悬挂提交/ blob,它们来自哪里?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆