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

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

避免人员误操作出现问题

首先是需要规范一套多人协作使用git分支的流程，当这套流程熟悉的运转起来了，也是可以适当的减少问题。即使出现问题也可以按照预设的处理问题的方案快速解决他
新入职的员工前一两个星期尽量去避免做一些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

写在最后

工欲善其事必先利其器