git server“丢失”commit问题探究

本文详述了一起在Gitlab上发生的部分代码文件内容丢失的情况,追查过程中发现commit bfff1f51疑似丢失。通过gitlab server的日志和network graph分析,确定是由于d5049b0分支进行了类似rebase的操作导致。结论强调了保护分支防止force push的重要性,并提出了改进措施。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

1 背景

gitlab某仓库有同事发现部分代码文件内容丢失,具体表现

A. dev分支commit信息是连续的,看不出明显的大时间范围批量丢失

file

B. 以SuncardCashier/control/CSymbolEdit.h为例,在1c88f613下只能看到2个历史相关提交

file

但是1天前提交的bfff1f51,也有此文件的修改提交,意味着bfff1f51这个提交“丢失”了

2 追查过程

2.1 gitlab server侧寻找线索

表面上像是gitlab server出现了某些问题导致“丢失”,所以查看/var/log/gitlab/gitlab-rails/下的production.log日志(production.log是当天的,production.log.31.gz是更早日期压缩后的,需要解压查看)。

但是通过查看日志只有一些查看上述commit的api access log,并无有效线索。并且同时段的其他仓库可以看到commit信息

2.2 gitlab network graph寻找线索

此时怀疑是有人在本地误使用rebase等命令再force push导致server的commit丢失,通过gitlab的network g

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值