​目录 

前言

问题

解决

前言

Git 是一个分布式版本控制工具，用于敏捷高效地管理任何或小或大的工程项目。这一点，我相信大家都知道。但是，如果我说它是开源的，你是不是突然来了兴趣？开源？是的，我们今天讨论的内容和这个没有关系（嘿嘿）。Git 在我们日常开发工作中经常会被用到，只要你在敲代码，几乎每时每刻都在和 Git 打交道，当然，这个过程中我们也会遇到各种各样的问题。

问题

大家好，我是 Data-Mining，别名 liuzhen007（中国邦德，一个敲代码的邦德），今天我又遇到了一个和 Git 相关的问题。

事情是这样的，为了实现对象存储服务的下载功能，我在一个 Git 分支上修改了很多代码，但是越改越乱，难免的。有时候敲代码就像画画，画着画着，自己也不知道自己在画什么了。

​

A：推翻了，重来！

B：嗯！

C：干！

D：。。。

D：干不动。。。

代码重置失败了。。。

尴尬。。。中国邦德想撤销当前的修改，怎么就干不动呢！

当时，中国邦德执行了如下命令：

git reset --hard

结果 Git 提示发生了如下错误：

fatal: Could not reset index file to revision ‘HEAD‘

解决

其实导致这个问题的原因有很多，包括但不限于如下解决方法。

方法一、以管理员身份运行Terminal或者Shell终端。

这个问题很容易理解，也比较常见。所以，我推荐优先考虑这种解决方法。

方法二、删除工程，重新clone。

哈哈，这个方法是不是很彻底？直接排除了 Git 自身的问题。如果我们遇到了方法一不能解决的问题，那么建议直接使用该方法。

也算是节省时间的终极大招了。

那么，还有这个方法解决不了的问题吗？

是的，比如方法三中遇到的问题。。。

方法三、清理磁盘空间。

你可能会问：还能用到这种方法？

是的，机器磁盘空间不足了，我今天遇到的就是这个情况。

一查原因，原来是docker容器的日志把磁盘占满了。

可以参考使用如下命令查看磁盘的占用情况：

find /home/boom/docker/containers/ -name *-json.log |xargs du -sh

不查不知道，一查吓一跳！

一个容器的日志居然跑了341G！！！

截图为证，我没有错怪谁：

​

通过上图，我们只是知道了一个容器的日志文件那么大，但是它是哪个容器的呢？

我们根据 ID，继续排查。

使用如下命令：

docker container ls | grep 25ddfc

查询结果：

​

哦，原来是一个叫 digibird/ordovician-usm 的容器搞的事儿。

通过日志信息分析，我们可以知道，这个容器仅仅启动了23个小时，就产生了341G的日志，天啊！这个容器是专门生产日志的吗？

先停了吧，把日志删了再说！

好了，至此，我们终于破案了。。。撒花+掌声。。。评论+点赞+收藏。。。

最后，你还遇到哪些原因导致了 Git 重置代码失败的情况，欢迎评论留言！

​