阅读 8605
学点Git高级技能来为同事擦屁股

学点Git高级技能来为同事擦屁股

在我们日常的开发中,当遇到误操作git仓库时,怎么及时的抢救,都是血淋淋的教训。相信每个程序员或多或少都有遇到过不同程度的问题,有些问题可能是粗心误操作造成的,有些可能是个人能力问题,新手使用git就很容易出问题。下面来聊聊一方面是怎么避免出现问题,另一方面是出现了这个情况怎么快速的处理它

避免人员误操作出现问题

  1. 首先是需要规范一套多人协作使用git分支的流程,当这套流程熟悉的运转起来了,也是可以适当的减少问题。即使出现问题也可以按照预设的处理问题的方案快速解决他
  2. 新入职的员工前一两个星期尽量去避免做一些merge操作,如果是不熟悉git使用流程的那就更不要操作,入职导师前期做好引导

流程规范

截屏2021-09-09 下午2.53.15.png

流程方面,这个是我在实际开发中拟定的一套流程,可能没那么完善,有更好的建议可以在评论区告诉我

在一般上点规模的团队,都会有一个迭代节奏,例如一周一小迭代两周一大迭代,每周会有一个固定的评审时间窗口,一个固定的发版时间。

拿我们当前的实际节奏举例,节奏是一周一小迭代,两周一大跌大,每个周五会集中评审下一个迭代的需求,每周三会集中发版,碰到大需求,顺延到下个周三发版,再大的需求就需要拆解或者是走单独版本来处理。

分支管理:负责人会从master来出一个开发分支,例如下一个版本是0915,就是拉一个20210915-release作为正常迭代版本的分支,每个开发人员再从20210915-release拉出一个自己的开发分支进行编码,编码完成之后统一合到20210915-release分支发布测试,这个时候切忌删除个人的开发分支,后面bug处理还是在自己的开发分支进行。当测试完成之后,可以从master拉出一个发布分支,也可以用当前测试分支发布到灰度环境,灰度环境验证通过后,确认发布线上时,提一个merge request给负责人,合到master后,打好tag,最后用tag发布到线上环境。

这里使用提 merge request 的方式,就是为了保证 master 代码的安全,尽可能的避免误操作了 master 的代码

异常情况的处理:当在开发的过程中,有个别需求暂停的异常情况时,我们就会启动异常流程,举例(20210915-release),将当前的正常迭代分支废弃,从新重master拉一个迭代分支(20210915-release-01),之后各个开发人员将自己的正常上线的代码合到20210915-release-01,暂停需求的代码不合进来,发布测试、 整体做回归测试,通过后在走正常发布流程。

当出现误合分支的情况,怎么快速的处理

举个 🌰 ,当在合分支时,误将不需要的一串commit合到了目标分支,怎么把它拎出来

重置到选定提交(commit已经提交到origin的情况)

截屏2021-09-09 下午6.33.43.png

比如:内容修改222、内容修改333、内容修改444这三条commit都是我不想要的,怎么摘除这几个commit。 选中内容修改111,右击

截屏2021-09-09 下午3.52.29.png

截屏2021-09-09 下午6.32.34.png

选中强行合并-丢弃所有工作副本改动,点击确认

截屏2021-09-09 下午6.36.56.png

继续点击 确认

截屏2021-09-09 下午6.37.14.png 将提交重置到了内容修改111commit,此时,由于这个重置操作只是作用于本地的暂存区,origin端没变动,所以落后origin端三个commit

截屏2021-09-09 下午6.39.46.png

注意:这个时候,你会遇到一个问题,总是显示落后origin几个commit,当你从origin拉下来,又回到了误操作的最初错误。怎么弄都是错的,尤其是涉及到了很多文件的改动时,自己根本无法甄别哪些代码是不要的,反倒会出现新问题

别慌,是因为你少了另一半操作,集中注意力往下看

选中内容修改444提交,鼠标右击

截屏2021-09-09 下午6.42.25.png

这次选中软合并-保持所有本地改动选项

截屏2021-09-09 下午6.44.34.png

操作完成后,souretree上呈现如下,origin端就清除了内容修改222、内容修改333、内容修改444提交的内容,并把相应的变动在本地体现了。点击提交,就把误操作的三次提交内容删掉了。

截屏2021-09-09 下午6.46.59.png

总结:第一次重置选中想要回退的目标提交记录,使用模式一定要选中强行合并-丢弃所有工作副本改动 第二次重置选中最后一次提交记录,使用模式 (推荐) 软合并-保持所有本地改动

重置到选定提交(commit保留在本地的情况)

截屏2021-09-09 下午5.28.39.png commit保留在本地的情况,我要重置到test111提交,选择commit,右击

截屏2021-09-09 下午5.34.50.png

此时,就成功的回到了想要重置的commit,test222 test333提交就回到了本地开发区 截屏2021-09-09 下午5.35.35.png

这个操作,就达到了我们预期的目的,回到了指定提交。还有一个好处,origin端没有你的失误记录,你的领导也看不见,可谓是毁尸灭迹。不仅把问题解决了,还让别人没法发现你的失误。

结论:我们可以频繁的commit本地改动到本地暂存区,必要时才推到origin

选定提交拉分支

截屏2021-09-09 下午5.55.54.png

这种方式相对于将test111提交及以前的代码单拎一条分支来,再相应的源码复制出来,然后把分支切回出问题的分支,将拉出新分支复制出来的源码 覆盖 出问题分支的对应源码,此时本地IDE就可以清楚的看到变动的文件,提交即可解决。这种解决办法就是我们常人可以很快理解的思维去解决的,虽然有些傻大黑粗。

查看某个文件所有的改动日志

截屏2021-09-09 下午7.13.07.png

选中对应文件,又击,选中查看选中的修改日志...,就是可以清楚的呈现这个文件所有的改动记录,避免同事之间胡乱甩锅

截屏2021-09-09 下午7.14.29.png

写在最后

工欲善其事必先利其器

文章分类
前端
文章标签