代码提交总体要求
- 每做完一个小的完整内容，就要提交
最好每做完一个小的完整内容就提交，这里建议提交，而非用一定要提交的强制语句，就是给大家一定的自由。但是随着大家工作经验的增长，在多次遇到要审查代码改动来解决重大问题时，会越来越有最好每做完一个小的完整内容就提交这种感觉。可能大家做的多是写业务功能相关的项目开发，所以感触不太深。但在平台级或框架级项目开发时，会有特别深的感触。有时感觉就改了一行代码就提交一次太麻烦，但是这样是有利于清楚表达这次提交的意义的。
- 每次提交要通过vs code或其它工具的代码差异工具来再三审查是否是自己要的改动。
大家都是有一定工作经验的，应该能对整齐简洁的代码感到赏心悦目。每次看到问题代码应该有种羞愧感，特别是因为马虎导致的时候。只有这样不断严格要求自己，才能不断提升自己的技术水平。提交前再三审查代码改动就是确定提交内容和再次整理思路过程, 可以有效避免错误提交代码.
代码merge带来问题的分析
图1
图2
图3
图2是有位同事的代码改动, 仅仅就是注释了一行，但由于改动基点之后有了新的推送，导致推送代码产生merge记录(即:图3)。图3截的图只是实际的改动的十分之一左右.这个merge记录的改动分析就非常麻烦了，可以看到merge记录的代码改动是非常大的，它往往是改动基点和merge之前的其它同事的所有改动。但这个也不是绝对的，大家知道出现冲突时人工合并代码也是产生merge记录，因此merge记录里有可能是人为改动的。在这种大量的改动里要找出人为改动的代码非常困难。如果在推送这个提交之前，git rebase 一下，就可以将基点改为“整理接口对接”而非“客户通加上常用搜索”。那么提交就会变成仅有一个“hidden”，代码改动将变得异常清晰。
代码提交具体流程细节
鉴于上面的原因，我不太建议多分支开发方式。为了减少merge记录，建议在代码仓库里添加了两个钩子，会在提交（commit)时先拉取（pull)代码。会在推送（push)代码时先变基（base)。
- 提交（commit)代码：
由于会先pull代码然后才执行commit，如果pull失败，那commit就不会执行。那什么时候pull会失败呢？当本地的代码可能和远程的代码冲突时，就会pull失败。这时我们怎么办呢？我通常的办法是执行 git stash 来暂存本地改动的代码，这时执行pull可以顺利成功了。这之后再执行 git stash pop 弹出刚才暂存的代码改动。这时可能出现冲突，那要解决冲突。再执行commit就可以了。
- 推送（push)代码：
由于push之前先执行 rebase，这时如果本地还有未commit的代码，可能就会base失败，从而push失败。这时我通常还是先stash代码再push代码，这时就可以顺利push了。
注意 如若需要本地执行分支合并, 就要暂时关闭这个git 钩子, 否则可能导致推送不了.
