同事rebase解了10次冲突,写了一篇建议

2,994 阅读4分钟

最近正式上班之后发现其实对于Git团队合作,其实是有很多“自我要求”,或者团队要求在其中,对于整体的项目开发规范大致梳理了一下,可能不太完整,具体的建议可以继续沟通改进👊。

本篇章重点侧重于代码提交前以及代码合入前的一些操作

Commit提交前

  1. 自我代码CR

工作中最常忽略的一个步骤

在工作中,我们会对代码进行频繁的更改,假设本次需求我们对10个文件进行了更改,那么在我们进行一次Commit之前我们需要干什么?

首先,对我们改动的每一处代码进行code review,避免将一些开发中用来调试的代码和无意义的代码带到线上。

如果不进行自我code review,会出现什么问题?

  1. 会在提交的代码中携带用来调试的log日志以及debugger等劣质的代码
  2. 会不经意间将开发中残留本需删除的代码,为同事进行代码cr制造困难

那么这样做会有什么好处?

  1. 二次验证自己开发逻辑,及时发现逻辑漏洞。
  2. 对自己的代码进行把控,避免调试代码以及无意义的代码被合入分支,包括一些本地自用的配置文件。

如何做?

巧用编辑器中的Git管理工具,以下均使用vscode的Git管理工具来进行示范

在Git管理工具中,我们可以看到当前我们本次提交的改动,去点击改动的文件查看文件的改动对照即可。

在对比之后,确保我们的提交是符合预期的,这时候就可以进行commit了。git提交规范,这里不加赘述。

代码合入前

目前公司的开发规范通常为,分支开发最终合入生产分支,一次需求,我们往往会在完成一次功能的时候进行一次commit,以达到原子性提交的目的

这样一方面能让自己对功能开发有一些把控,另一方面方便团队成员进行CR。

但是在代码CR之后,我们却不能带着这么多的commit合入,当我们带着如此多的commit合入主分支,那么主分支即使是单线的,那么历史也会有一些混乱,你有可能依旧分不清那个commit属于那个需求。

如果不压缩代码会出现什么问题?

  1. 虽然一直保持rebase合入,但是master分支的历史记录依旧繁多混乱,无法分清commit和需求直接的关联关系。
  2. 在同事要rebase最新的主分支时,要去对比你一次需求的10个提交,最坏的结果是,同事需要把10次提交的冲突都解决掉才可以rebase成功,风险极大且费时。

如何解决上述问题?

  1. 对 commit 进行压缩

在代码合入前,对代码的commit进行压缩,使用 git squash。

举个🌰

当你完成需求并提测之后,测试同学指出了你的问题,你对问题进行了一些修复,那么我们知道 fix: 提测问题修复是不允许合入到主分支的,那么我们需要对它进行 git squash。

git squash 其实是对 git rebase 一套指令的使用

在下面的图片中,可以看到,我们输入了git 指令之后,它显示了我们的commit 记录,我们可以看到 Commands 里面有对应的指令(有些很有用),其中就有我们的 squash.

将要合并的代码前缀改成 s

当保存之后,就出现下面的情况,让你对提交进行操作,那么我们可以在这里修改commit文案,以及注释掉不需要的commit,最终保留一个commit。

那么我们就会发现git的历史提交已经被更改了

现在会提示你,你需要同步远程代码

这个时候是因为,压缩生成的commit的 hash 和远程被合并的commit是不一致的。

这个时候需要

// 强行覆盖远程代码
git push -f

git push -f 需要谨慎使用,使用前要确保当前分支只有自己开发

本文讲了一些代码提交的建议,希望对你有所帮助👊。其实还有一些细节,但是最重要的还是对自身的要求啦

祝诸君,武运昌隆