最近正式上班之后发现其实对于Git团队合作，其实是有很多“自我要求”，或者团队要求在其中，对于整体的项目开发规范大致梳理了一下，可能不太完整，具体的建议可以继续沟通改进👊。
本篇章重点侧重于代码提交前以及代码合入前的一些操作
Commit提交前
-
自我代码CR
工作中最常忽略的一个步骤
在工作中，我们会对代码进行频繁的更改，假设本次需求我们对10个文件进行了更改，那么在我们进行一次Commit之前我们需要干什么？
首先，对我们改动的每一处代码进行code review，避免将一些开发中用来调试的代码和无意义的代码带到线上。
如果不进行自我code review，会出现什么问题？
- 会在提交的代码中携带用来调试的log日志以及debugger等劣质的代码
- 会不经意间将开发中残留本需删除的代码，为同事进行代码cr制造困难
那么这样做会有什么好处？
- 二次验证自己开发逻辑，及时发现逻辑漏洞。
- 对自己的代码进行把控，避免调试代码以及无意义的代码被合入分支，包括一些本地自用的配置文件。
如何做？
巧用编辑器中的Git管理工具，以下均使用vscode的Git管理工具来进行示范
在Git管理工具中，我们可以看到当前我们本次提交的改动，去点击改动的文件查看文件的改动对照即可。
在对比之后，确保我们的提交是符合预期的，这时候就可以进行commit了。git提交规范，这里不加赘述。
代码合入前
目前公司的开发规范通常为，分支开发最终合入生产分支，一次需求，我们往往会在完成一次功能的时候进行一次commit，以达到原子性提交的目的
这样一方面能让自己对功能开发有一些把控，另一方面方便团队成员进行CR。
但是在代码CR之后，我们却不能带着这么多的commit合入，当我们带着如此多的commit合入主分支，那么主分支即使是单线的，那么历史也会有一些混乱，你有可能依旧分不清那个commit属于那个需求。
如果不压缩代码会出现什么问题？
- 虽然一直保持rebase合入，但是master分支的历史记录依旧繁多混乱，无法分清commit和需求直接的关联关系。
- 在同事要rebase最新的主分支时，要去对比你一次需求的10个提交，最坏的结果是，同事需要把10次提交的冲突都解决掉才可以rebase成功，风险极大且费时。
如何解决上述问题？
-
对 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 需要谨慎使用，使用前要确保当前分支只有自己开发
本文讲了一些代码提交的建议，希望对你有所帮助👊。其实还有一些细节，但是最重要的还是对自身的要求啦
祝诸君，武运昌隆
