这里列出了若干在使用版本控制的过程中容易出现的常见问题，这些问题来自实际
工作中的切身体会。但是，这个问题列表未必全面，并且对于具体个人而言，其情形也不尽相同。每个使用版本控制的开发人员的心里可能都有一个类似这样的列表，并且在实际开发中，或许这个列表还会得到扩充，不断完善。
Item 1. 项目的逻辑结构混乱（这里的“项目”是版本控制中的术语，见A.1）
这是在实施版本控制过程中一个容易出现的问题，尤其是对于项目开发（此处非术语）。其原因有很多，比如：开始时对需求不明确，导致软件本身结构混乱，使 在定义软件的逻辑结构时，时常变化。又如：一个团队中，大家各自都之关心自己负责的模块，每个人各自制定适合自己的逻辑结构，导致最终的项目结构是一个大 杂烩（多个结构组合而成）。久而久之，就会导致软件管理混乱，增加维护负担，反而降低效率。结构中，有的目录可能是“死角”，永远都没有使用到；有的目录 可能是重复的，造成冗余；有的目录可能大家同时在用，各自对代码的修改彼此影响。自始至终合理安排和规划项目的逻辑结构，这是一定需要坚持的。
Item 2. 多人修改同一个文件
一旦出现这样的情况，很有可能某人辛勤劳动的成果，会被别人毁于一旦。其解决办法是：在一般情况下，确保在任何时刻都只有一个成员对某个特定的文件进行 修改，这样可以防止文件被其他成员的修改意外更新。为了适应多人同时修改同一个文件的情况，版本控制管理员也可以改变此缺省设置以允许对单个文件同时有多 个签出（checkout），并且仍禁止对他人的修改进行覆盖。
Item 3. 本地版本和服务器版本不一致
有时会碰到这样的情形，开发人员在从服务器那里更新本地版本时，只更新了部分内容，导致本地编译不通过。应该时刻注意保持本地版本和服务器版本的一致 性，这是一个认识的问题，因为服务器版本才是真正唯一有效的。多个程序员还必须注意不要为了解决同一个问题而浪费时间。对某项功能的实现，由于本地和服务 器的不一致，导致大家重复实现。应该对服务器端数据的全部内容，包括所有子文件夹，定期进行备份，这是绝对重要的一项工作。
Item 4. 用户权限混乱
对于所有开发人员和各自负责的模块，根据实际情况，制定合理的用户权限，哪些人对哪些目录只有可读权限，哪些人对哪些目录有读写权限。不应该出现所有人都是管理员这样的极端情况。
Item 5. 手工修改文件的只读标记
为了防止你对没有签出的文件进行修改，版本控制管理工具会将这些文件指定并标明为只读文件。当你签出一个文件时，只读标记便被删去。一种经常出现的不良 习惯是，为了图省事，在没有签出文件时便试图修改文件，当发现文件不能保存时，便手工修改其只读标记。这是一切混乱的“源头”，它将导致不一致、有效内容 被覆盖等问题。
Item 6. 没有指定工作目录或存在多个工作目录
每个开发人员必须拥有一个独一无二的工作目录，它不能与任何其他开发人员共享（这里的“工作目录”是版本控制中的术语，见A.2）。
Item 7. 频繁的签入或很少签入
掌握好签入的时间，比如一天，或者在其他人需要的时候。并非每次微小的改动都需要马上签入，也并非每改完一个文件都将其签入，但也不要忘记签入。
Item 8. 从服务器上获取最近版本时的疏忽
如果选择获取当前已经签出并且已经修改的文件最新版本，操作时必须非常小心。如果你选择取代文件，你将用最近一次签入的文件版本改写你做的修改，这可能会使你所做的工作白费。大多数情况下，最保险的做法是选定Apply To All Items，并选择Leave。
A 软件版本控制中出现的几个主要概念
参考Visual SourceSafe，这里列出几个主要的基本概念。
A.1 项目（Project）
版本控制的一个单位，包含若干不同类型的文件。其下所属代码及相关文档，以目录结构分别存放。一个软件可以对应一个或多个项目，视情况而定。
A.2 工作目录（Working Folder）
开发人员对项目文件进行调试修改的地方，一般位于本地机器上。开发人员签出（checkout）项目中的文件时，将被拷贝到工作目录下，当修改完文件后，开发人员再将文件从工作目录签入（checkin）服务器。
相关链接：
没有使用版本控制的黑暗时代——版本控制心得（一）
版本控制之我见——版本控制心得（二）