当今的软件开发更多是团队合作，团队的所有成员均工作在同一份代码库上。这样即便是有了先进的版本控制管理工具（诸如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到乙的版本，然后再做出自己的修改。不过此前要做好代码的备份，否则一旦执行这些命令，甲之前所作的修改就会瞬间消失。

本文翻译自”You Gotta Care about the Code“，来自于《程序员应该知道的97件事》一书中的某个章节。

即使不用大侦探福尔摩斯，我们也能知道优秀的程序员能写出好代码。糟糕的程序员…则不能。他们生产出代码巨兽，而其他人则不得不去清理。你想写出好代码，对不对？你渴望成为一名优秀的程序员。

好代码不会凭空冒出来。它也不是什么需要各大行星排成一列时靠运气才发生的事情。为了写出好代码，你必须在代码上下足功夫。这的确很难。并且如果你真正地关心好代码，你也只是得到这些好代码，仅此而已。

优秀的编程能力不单纯来自于技术能力。我曾经看到过很多智力超群的程序员，他们可以实现出精细的且令人印象深刻的算法，他们对语言标准烂熟于心，但他们编写出的代码却是最糟糕的。这些代码难于阅读，难于使用，并且难于修改。我还曾见过一些谦卑的程序员，他们坚持编写简单精炼的代码，不过他们却可以写出风格优雅且极具表现力的代码，能在工作中使用这些代码不失为一件乐事。

基于我在软件行业多年的经验，我得出这样的结论：那些可胜任工作的程序员与伟大程序员之间的真正差别在于态度。优秀的编程在于能在真实世界的约束以及软件行业的巨大压力下采用一些专业的方法，并且由衷地渴望编写出最好的软件。

通往地狱的代码是用良好的意愿铺成的。要成为一名优秀的程序员，你必须克服良好意愿的影响，并且真实地去关心你的代码 –培养积极的观点，形成健康的态度。伟大的代码是由工匠大师们精心制作的，而不是由粗心程序员草率编写的或者由某些自称编程大师的人故弄玄虚地创建的。

你想编写出好代码。你想成为一名优秀的程序员。因此，你就应该关心你的代码：

·在任何编码的情况下，你都应该拒绝在那些只是看似能运行的代码上工作。你应该力求精心制作一份优雅且完全正确的代码（并有良好的测试用例可以证明你的代码是正确的）。

·你编写的代码应该是可发现的（其它程序员可以很容易地学会和理解），可维护的（即你或者其它程序员在将来可以很容易的修改这些代码），以及正确的（你需要采取一切可能的措施确保你已经解决了这个问题，而不只是让程序看似是可以工作的）。

·你和其它程序员一起工作。没有程序员是孤立的。很少有程序员独自工作；程序员团队所从事的大多数工作要么是在一个公司环境中，要么是一个开源项目。你要顾及其它程序员，并且构建其它人可以读懂的代码。你希望团队能编写出尽可能最好的软件，而不是使自己看起来很聪明。

·任何时候你遇到一段代码，你都应该力求将它改造得比之前更好（要么结构更优，要么更易测试，要么更易理解）。

·你关心代码和编程，所以你持续不断的学习新的语言，惯用法以及技术。不过你只能在适当的时候应用它们。

幸运的是，你正在阅读这些建议，那是因为你确实关心你的代码。你感兴趣。这是你的激情。快乐地编程。享受制作代码解决棘手的问题的乐趣吧。生产出让你感到骄傲的软件！

By Pete Goodliffe