关于代码提交的思考
今天晨会的时候就代码提交展开了一场讨论。
关于代码提交，从工作之初到现在我一共经历了三个阶段。
一阶commit
第一个阶段，想起了就提交一次，有时候可能每天都会提交，有时候没想起可能一两个星期才提交一次。这么久才提交一次代码难免被部门老大批评，为了不成为批判对象，我洗心革面，于是进入第二个阶段。
二阶commit
第二阶段的我，每天下班的时候提交一次代码，不仅部门老大再也没有说过我，我自己也觉得特别充实：每天都提交那么多代码，感觉自己棒棒哒。但慢慢的我发现这也存在一些问题：
1.如果那天做的模块很复杂，到下班都没有完成，commit会是这样的：
git commit -m '商品详情页完成60%'
2.如果当天完成了几个小功能模块，commit会是这样的：
git commit -m '菜单栏封装完成、侧滑栏封装完成、弹窗封装完成'
3.如果当天做了两个模块，一个完成一个未完成，commit是这样的：
git commit -m '部门销售模块完成，门店销售模块完成40%'
这种commit虽然比一两个星期才提交一次代码的commit好很多，但它依旧谈不上好。要么不具体，如商品详情页完成60%；要么冗杂，如菜单栏封装完成、侧滑栏封装完成、弹窗封装完成。由于我对自己的要求比较高，于是乎，自然而然的进阶到了第三个阶段。
三阶commit
第三阶段的我完全领悟commit之真谛，反手就是一个优雅commit！其宗旨就是：只要完成一个小功能或者小模块就提交一次（也包括临时完成一个产品需求或者改了一个bug）。比如说：
1.你完成了toast的封装：
git commit -m 'toast封装完成'
2.你正在开发，产品那边叫你修改一个图片尺寸（这个时候你或许需要git stash），你改完后也可以提交一次（即使只改了一行代码）：
git commit -m '调整商品详情页的商品图大小'
3.线上发现bug，立即修复并提交：
git commit -m '修复xxxbug'
这样做的好处有：
- 方便自己核查自己的代码。
- 方便队友code review，就一个小功能，三言两语就能阐述清楚，代码量也小，队友能更好的把控审核重点。
- 方便自己复查以前提交的代码。
- 版本回滚，造成的损失相对较小。
对部门规定的思考
我们部门的规定是：提交代码，不能超过两天。
我个人认为这个规定有一定意义，又不是很有意义。
很显然，这个规定要求我们提交代码不能拖太久，因为一旦拖久了代码量大了会给code review带来很大的难度，想象一下一次性审核几千行代码会是怎样一种体验。
但是，仅仅不超过两天是不够的，有的人一天就能写上千行代码，code review的时候压力也不小，如果他完成模块不止一个，那commit就会是：
git commit -m '首页侧滑栏完成，详情页菜单栏完成，商品列表完成30%'
这种commit就显得很杂乱。
如果改成：
git commit -m '首页侧滑栏完成'
git commit -m '详情页菜单栏完成'
拆分一下，code review的时候会轻松很多，commit内容也更清晰。
综上我认为部门的这个规定只是告诉了我们不能怎么做，但是没有告诉我们应该怎么做。这只是一个针对新手、避免新手明显犯错的强制规定。具体该怎么做，看上面写的三阶commit或者直接看下面的总结。
总结
就一句：完成一个小任务就提交一次代码。
