git server“丢失”commit问题探究
2020-05-08 16:04:49来源:博客园 阅读 ()
git server“丢失”commit问题探究
1 背景
gitlab某仓库有同事发现部分代码文件内容丢失,具体表现
A. dev分支commit信息是连续的,看不出明显的大时间范围批量丢失
B. 以SuncardCashier/control/CSymbolEdit.h为例,在1c88f613下只能看到2个历史相关提交
但是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 graph是一个高效的梳理手段
首先在network grapsh搜索bfff1f51(灰色箭头指向),这也说明gitlab server其实有此commit数据
这里不同颜色线相当于是dev分支不同的提交人,最右侧红线为主分支,其中线之间的箭头是merge。查看图中bfff1f51之后各线最邻近的merge,基本都还可以看到bfff1f51这个提交,说明正常。除了红色箭头标识的左侧绿线!
此提交为d5049b0,可以看到该文件已经没有bfff1f51提交了
继续到绿线分支更后的操作追查,之后它merge到了粉线(左起第二),粉线再merge到了兰线(左起第三),粉线再merge到了红线(左起第四)。而“丢失”情况如下图示,即被绿线merge前都正常,merge后都丢失了
3 结论
至此,可以基本确定是d5049b0进行了类似rebase回滚到之前提交的行为(其commit message也填写的是“冲突”),另外可以看到该仓库设置的protected branch只有master,无dev,所以是具备force push条件的
4 建议的改进措施:
A. 将dev等需重点分支禁止force push
B. 开发人员对于git回滚等操作需谨慎对待
“用来记录生命的演进,故事的迭代。期望做一个给大家带来帮助和思考的平台” ——深邃老夏
原文链接:https://www.cnblogs.com/deepsummer/p/12849092.html
如有疑问请与原作者联系
标签:
版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有
- 用 Git 和 Github 提高效率的 10 个技巧! 2020-06-10
- 前端 技术之 Git&GitHub 2020-05-29
- Git 高级用法,喜欢就拿去用! 2020-05-18
- centos7-linux下docker安装Gitlab中文社区版 2020-05-15
- git远程仓库,gitblit安装(war包方式) 2020-05-15
IDC资讯: 主机资讯 注册资讯 托管资讯 vps资讯 网站建设
网站运营: 建站经验 策划盈利 搜索优化 网站推广 免费资源
网络编程: Asp.Net编程 Asp编程 Php编程 Xml编程 Access Mssql Mysql 其它
服务器技术: Web服务器 Ftp服务器 Mail服务器 Dns服务器 安全防护
软件技巧: 其它软件 Word Excel Powerpoint Ghost Vista QQ空间 QQ FlashGet 迅雷
网页制作: FrontPages Dreamweaver Javascript css photoshop fireworks Flash