Git commit提交粒度的思考
提交粒度考虑
在Git项目开发过程中经常需要考虑的一个问题，即修改提交COMMIT的粒度如何选择。如果粒度太细，很多提交可能没有意义，合并到开发分支（如果保持线性记录的话）太多这种提交会给团队其它人员造成困扰；但如果太粗，又会导致查看前面某个节点的版本快照以及版本回退困难。
所以COMMIT提交粒度应该把握”适中“原则。我认为一个COMMIT提交应该是一个完整的子任务（subtask），比如按照函数级别的提交粒度，同时要保证提交时程序完整、能够正常运行。
善用amend补救提交
在开发过程中我们经常遇到这样一个场景：完成一部分代码的开发，虽然完成度还不高，但希望放进Git版本库中保存，中途可能有其他事去做。
当后续继续开发时下一次提交实际上内容和上一次提交紧密相关的，使用新的COMMIT提交没有必要，此时可以考虑使用补旧时提交。
$ git add file # 将文件添加到暂存区
$ git commit --amend
# 进入COMMIT信息编辑窗口，编辑提交信息在git commit时加上参数--amend可以合并上一个COMMIT提交内容，需要注意的是此时会生成一个新的COMMIT哈希值。
如果不需要编辑提交信息，可以添加--no-edit参数使用上一次提交信息。
$ git commit --amend -no-edit实践
比如我在做代码优化工作时，对于一个大的函数需要进行优化，我会采取增量式开发方式，不断的修改部分代码并使用--amend方式提交到Git版本库，最终对于这个函数的优化只提交了一个COMMIT。
注意事项
如前面所说，使用--amend提交会产生一个新的COMMIT哈希值。如果你将上一次提交推送到共享版本库中，再使用补救式提交会导致本地版本记录与共享版本库中不一致，相当于你修改了过去版本记录。如果其他人下载了上一个提交的版本就会产生麻烦。
因此，在使用--amend提交方式开发时不要推送到共享版本库，完成子任务工作后再推送。
当然，你也可以使用git push -f强制推送，但确保推送的分支别人未使用。
如果想整理过去多个历史版本记录，可以考虑使用git rebase -i，一般在推送到共享版本库发起PR前执行整理工作，保持版本记录的整洁。这同样会改变版本历史记录，因此在推送到共享版本库后谨慎使用该操作。
