2.7　更好用的提交列表

正确的版本控制系统的使用方法是，一次提交只干一件事：或是完成了一个新功能，或是修改了一个Bug、或是写完了一节的内容，或是添加了一幅图片，就执行一次提交。不要在下班时才想起来要提交，那样的话版本控制系统就被降格为文件备份系统了。

但有时在同一个工作区中可能要同时做两件事情：一个是尚未完成的新功能，另外一个是解决刚刚发现的Bug。很多版本控制系统没有提交列表的概念，要么需要在命令行中指定要提交的文件，要么默认把所有修改内容全部提交，破坏了一次提交只干一件事的原则。

1.SVN的解决方案

SVN 1.5开始提供变更列表（change list）的功能，是通过引入一个新的命令svn changelist来实现的。但是我从来就没有真正用过，因为：

定义一个变更列表太麻烦。例如，没有一个快捷命令将当前所有改动的文件加入列表，也没有快捷命令将工作区中的新文件全部加入列表。

一个文件不能同时属于两个变更列表。两次变更不许有文件交叉，这样的限制不合理。

变更列表是一次性的，提交之后自动消失。这样的设计没有问题，但是相比定义列表时的繁琐，以及提交时必须指定列表的繁琐，使用变更列表未免得不偿失。

因为Subversion的提交不能撤销，如果在提交时忘了提供变更列表名称以针对特定的变更列表进行提交，错误的提交内容将无法补救。

总之，SVN的变更列表尚不如鸡肋，食之无味，弃之不可惜。

2.Git的解决方案

Git通过提交暂存区实现对提交内容的定制，非常完美地实现了对工作区的修改内容进行筛选提交：

执行git add命令将修改内容加入提交暂存区。执行git add-u命令可以将所有修改过的文件加入暂存区，执行git add-A命令可以将本地删除文件和新增文件都登记到提交暂存区，执行git add-p命令甚至可以对一个文件内的修改进行有选择性的添加。

一个修改后的文件被登记到提交暂存区后，可以继续修改，继续修改的内容不会被提交，除非对此文件再执行一次git add命令。即一个修改的文件可以拥有两个版本，在提交暂存区中有一个版本，在工作区中有另外一个版本。

执行git commit命令提交，无须设定变更列表，直接将登记在暂存区中的内容提交。

Git支持撤销提交，而且可以撤销任意多次。

只要使用Git，就会时刻与隐形的提交列表打交道。本书第2篇第5章会详细介绍Git的这一特性，相信你会爱上Git的这个特性。