commit 和 push 的临界点

　　估计很多使用 git 的同学把握不住什么时候应该 commit， 什么时候又应该把未提交的 commits 都 push 上去， 今天我就把我的理解说一说。
　　首先，有一条原则应该是要遵循的： 提交描述 = 提交的修改。
　　凡是违背这一原则的都构成欺诈：

1. 提交描述 < 提交的修改

   　　这种情况是这次提交中 实际修改的内容比提交描述中介绍的要多， 难道你想添个后门？

2. 提交描述 > 提交的修改

   　　这种情况是实际修改的内容比提交描述中介绍的要少， 那不是偷工减料吗，我们不要做豆腐渣工程。

　　所以，提交的描述一定要精准。 git 的提交描述可以是多行的，描述的内容可以非常详细， 在不填写描述的情况下提交 git 弹出的这个对话框就介绍了这一点：

---

　　commit 是一次目的性明确的改动， 但改动的地方不宜过多（否则看起来会晕o(╯□╰)o）， 我们应该将一个功能分解为几个 commit， 一个 commit 负责一个部分的改动， 当这几个 commit 都完成了再 push。
　　这样做是因为没有 push 上去的提交保存在本地， 万一有什么当时没想好的，还可以修改 （未 push 的 commit 是有办法修改的，后续文章会讲）， 要是 push 上去了，最好就不要改了， 而是用新的 commit 来弥补 （git 允许冲掉以前 push 的变更：git push -f）。
　　照以上的建议来做的话，可以保证每个 commit 的质量，以致提高每个功能的质量。

　　最近学 SVN 版本管理，SVN 是直接 commit 到远程的， 也就是说它不允许像 git 这样收集几个 commit， 等觉得没问题了，再推送到远程，这样就不太好了。