当今的软件开发更多是团队合作，团队的所有成员均工作在同一份代码库上。这样即便是有了先进的版本控制管理工具（诸如Subversion、Git等），出现冲突（Conflict）的情况也是在所难免的。这就需要你学会解决冲突。

以Subversion为例，多数人在学习这类工具时都选择了浅尝辄止，仅仅停留在会使用update和commit这些常用的命令上。这样大家就错过了那些可以帮助你快速解决冲突的命令，以致很多人无论遇到任何冲突情况都采用了低效的全手工处理的方式。实际上不同的冲突情形处理的方式是有差别的。某些情况下，利用类似svn resolve这样的命令可以帮你快速解决冲突。我们应该有意识地采用一些专业的做法，不是吗？^_^

这里简单回顾一下版本冲突的产生过程：

- 版本库中存在一个代码源文件Foo.c，当前修订号：#BASE-REV；

- 甲、乙二人同时Checkout出文件Foo.c的最新版本#BASE-REV；

- 乙对其本地目录下的文件Foo.c进行了修改，并提交了代码，提交后文件Foo.c的修订号变为了#HEAD-REV；

- 由于缺乏沟通或沟通有误，在不知乙已经作出修改的情况下，甲也对其本地的文件Foo.c进行了修改；

- 当甲尝试将其本地目录下的Foo.c文件提交（commit)到代码库时，SVN给出错误提示：提交失败(细节如下): … …；或当甲尝试Update最新代码到其本地目录下时，发现SVN给出冲突提示："C    Foo.c"或在 “Foo.c” 中发现冲突…。

Subversion 1.5版本之前不支持所谓的"交互式冲突解决(interactive conflict resolution)"，而1.5之后的版本则支持这种交互式的解决过程，即当冲突时，你会在控制台上看到的这样的提示：

在 “Foo.c” 中发现冲突。

选择: (p) 推迟，(df) 显示全部差异，(e) 编辑, (h) 使用帮助以得到更多选项:_

如果你选择p，或者你用的是低于1.5版本的Subversion，你在执行svn update后会在你的本地目录下得到如下几个文件：

Foo.c  Foo.c.mine  Foo.c.r#BASE-REV  Foo.c.r#HEAD-REV

分别解释一下这几个文件：

Foo.c – 这个是由Subversion自动将版本库中的最新改动合并到你本地的一个包含了<<<>>>等标记的冲突文件；

Foo.c.mine – 这个是甲在执行svn update前自己修改的那份Foo.c文件；

Foo.c.r#BASE-REV – 这个文件的内容与修订号为#BASE-REV的Foo.c文件一致，也就是那份基（Base）文件；

Foo.c.r#HEAD-REV – 这个文件是乙修改后并提交的Foo.c文件，也是目前代码库中的HEAD revision。

那么甲如何来处理这个冲突呢？在不会使用svn resolve命令之前，甲很可能会这么做：打开Foo.c，逐个冲突进行解决。然后删除其余的三个Foo.c.xxx文件，最后提交代码。

这么做无可厚非，不过不是所有情况下都需要这么做的。我们将冲突情况进行一下分类：

1. 甲的代码完全包含了乙对Foo.c的修改，Foo.c.mine中的内容正是我们想要的;

2. 乙的代码完全包含了甲对Foo.c的修改，Foo.c.r#HEAD-REV中的内容正式我们想要的；

3. 甲、乙两人修改的代码确实存在不可融合之处，那么需要手工分析和解决Foo.c中的冲突。

下面我们用svn resolve命令分别处理上面三种情况：

针对情况1，甲可直接在自己的环境中执行svn resolve –accept mine-full Foo.c，执行后，冲突状态消失，甲可以从容地提交代码了；

针对情况2，甲可直接在自己的环境中执行svn resolve –accept theirs-full Foo.c，执行后，冲突状态消失，甲也可以从容地提交代码；

针对情况3，工具无法给予甲更有力的支持了，只能依靠甲自己去打开Foo.c并手工解决所有冲突了。待所有冲突解决后，执行svn resolve –accept working Foo.c或直接删除其它三个Foo.c.xxx文件，使冲突状态消失，Subversion这时将允许你提交你的代码。

有两点需要注意的是：

1. svn resolve命令只是在Subversion 1.5以及以后版本中才提供，在1.5版本前Subversion提供了一个resolved命令，不过这个命令似乎不是那么给力，基本上和你手工解决没啥差别，1.5以后这个resolved命令就被废弃了。

2. 对于第三种情况，一旦你删除了其余三个Foo.c.xxx文件，那svn就会认为你的冲突状态已经不存在了，这时即使你的Foo.c中依旧包含<<<>>>等冲突标记也是可以提交成功的，这里要小心对待。

另外对于情况3，如果甲并不想打开Foo.c手工解决冲突，而是想Undo自己的修改的话，那么甲可以通过执行svn resolve –accept base Foo.c或svn revert来将Foo.c恢复到#BASE-REV状态。接下来可以先update到乙的版本，然后再做出自己的修改。不过此前要做好代码的备份，否则一旦执行这些命令，甲之前所作的修改就会瞬间消失。

本文翻译自"Put Everything Under Version Control"，来自于《97 Things Every Programmer Should Know》一书中的某个章节。

把项目中的一切都纳入版本控制。你需要的资源包括：免费的工具，比如Subversion，Git，Mercurial和CVS；充足的磁盘空间；便宜且性能强大的服务器；无处不在的网络；甚至包括项目托管服务。安装好版本控制软件后，为了将你的工作成果放入版本库中，你所要做仅仅是在一个包含你的代码的干净目录中敲入适当的命令。你只需要学习两个新操作：将你修改的代码提交到版本库中以及将版本库中的代码更新到你本地的工作版本中。

一旦你的项目纳入版本控制，你就可以跟踪它的历史，看看谁写了哪些代码，并且可以通过一个唯一标识引用一个文件或某个项目版本。更重要的是你可以大胆地修改代码。不用担心删除掉那些为了以防万一而被注释掉的代码，因为老版本代码很安全地待在版本库中。你可以（且应该）用一个具有实际含义的符号给一个发布版本打上标签，以便你在将来可以很容易地重新找到客户那运行的软件的确切版本。你可以创建分支来进行并行开发：大多项目都有一个主开发分支以及一个或多个用于积极支持发布版本的维护分支。

版本控制系统减少了开发人员之间的冲突。当程序员各自工作在独立的软件部件上时，他们的工作好似用了魔法一样被整合在了一起。当他们之间出现冲突时，版本控制系统会通知他们，并允许他们对冲突进行分类整理。通过一些其他设置，系统会将每次变更提交通知给所有程序员，让大家共同了解到当前项目的进展情况。

当你创建完项目后，不要吝啬：将你的所有项目资产都纳入版本管理。除了源代码外，还包括文档，各种工具，构建脚本，测试用例，美工作品，甚至是库。全部项目被安全地塞入（定期备份的）版本库后，硬盘损坏或丢失数据所带来的损失将减到最小。在一个新机器上配置开发环境只需简单地将项目代码从版本库中检出即可。这将大大简化软件在不同平台上的发布、构建和测试过程：在每台主机上一个简单的更新命令就可以确保你获得的是当前最新的软件版本。

现在你已经看到使用版本控制系统的好处了，遵循下面几条规则会使你和你的团队更加高效：

· 每次提交一个逻辑变更。在一次提交中包含许多变更会导致后续很难弄清楚其中每个逻辑变更所对应的内容。这点在你进行项目范围内的重构或风格改变时尤其重要，一起提交多个变更很容易掩盖其他修改。

· 每个提交都要包含一个解释性的信息。至少简要地描述一下你修改了什么。不过如果你还想记录这次修改的理由，那这里就是存储它的最好地方。

· 最后，避免提交那些会破坏项目构建的代码，否则你就会成为这个项目中不受欢迎的人。

版本控制系统下的生活是如此美好，一些疏忽和过失都无法轻易地破坏它。

By Diomidis Spinellis