189 8069 5689
小编这次要给大家分享的是如何解决git server“丢失”commit问题，文章内容丰富，感兴趣的小伙伴可以来了解一下，希望大家阅读完这篇文章之后能够有所收获。
东丰ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景，ssl证书未来市场广阔！成为成都创新互联公司的ssl证书销售渠道，可以享受市场价格4-6折优惠！如果有意向欢迎电话联系或者加微信：028-86922220（备注：SSL证书合作）期待与您的合作！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回滚等操作需谨慎对待
看完这篇关于如何解决git server“丢失”commit问题的文章，如果觉得文章内容写得不错的话，可以把它分享出去给更多人看到。
另外有需要云服务器可以了解下创新互联建站www.cdcxhl.com，海内外云服务器15元起步，三天无理由+7*72小时售后在线，公司持有idc许可证，提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案，具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势，专为企业上云打造定制，能够满足用户丰富、多元化的应用场景需求。