本文翻译自"Fulfill Your Ambitions with Open Source"，来自于《程序员应该知道的97件事》一书中的某个章节。

如果你在工作中没能开发那些可以实现你雄心壮志的软件，那你将有很不错的机会。也许你正在为一家庞大的保险公司开发软件，然而你实际上却宁愿供职于Google、Apple、Microsoft或是你自己初创的公司去开发下一个对世界影响巨大的软件。如果你去为你根本不关心的系统开发软件，那你永远也实现不了你心中的抱负。

幸运的是，你的问题有一个答案：开源。那里有成千上万的开源项目。其中许多项目的开发都十分活跃，可以提供你想要的各种软件开发经验。如果你有了开发操作系统的想法，那就从十多个操作系统项目中选择一个加入吧。如果你想从事音乐软件、动画制作软件、加密技术、机器人技术、电脑游戏、大型网络在线游戏、移动电话或任何一类软件的开发，你肯定可以找到至少一个开源项目可以满足你的兴趣。

当然，这世上没有免费的午餐。你必须愿意牺牲一些你个人的自由时间，因为你在日常工作中可能无法从事一个开源视频游戏的开发 – 你还要为你的雇主负责。此外，只有极少数人可以从对开源项目的贡献中获得收入 – 有些人得到了，不过大多数人没有。你应该放弃一些你的自由时间（少玩些视频游戏，少看些电视也没啥大不了的）。你在开源项目上的工作越努力，你就会越快地实现你作为程序员的抱负。考虑你的雇佣合同也同样重要 – 一些雇主可能会限制你可以贡献的内容，即使是在你自己的自由时间里。此外，当你的工作涉及到版权，专利，商标及贸易机密时，当心侵犯知识产权法。

开源为那些激情十足的程序员们提供了巨大的机会。首先，你可以看到其他人是如何实现一个让你感兴趣的解决方案的 – 你可以通过阅读其他人的源代码学到很多东西。第二，你向这个项目贡献你的代码以及想法 – 不是所有你的好想法都将被接受的，不过其中的一些可能被接受。通过开发解决方案以及贡献代码你就可以学到一些新东西。第三，你会遇到那些对此类软件拥有和你同样热情的卓越的程序员 – 这些因开源项目合作而形成的友谊可能会持续一生。第四，假设你是一个称职的贡献者，你将在这门让你感兴趣的技术上积累许多实际经验。

开始参加开源项目十分容易。有很多有关你需要的工具（例如：源码管理工具，编辑器，编程语言，构建系统等）的文档资料。找到第一个你要参与的项目，学习这个项目所使用的工具。多数情况下有关这些项目自身的文档很少，不过这也无关紧要，因为学习开源项目的最好的方法就是自己研究这些代码。如果你想加入，你应该帮忙编写文档。或者你可以自愿编写测试代码。虽然这听起来也许不那么让人兴奋，但事实是为其他人的程序编写测试代码比几乎任何其它方式都能更快速地了解这个软件。编写测试代码，优秀的测试代码。找Bug，提交修正建议，结交朋友，参加到那些你喜欢的软件开发工作中，实现你软件开发的雄心壮志。

by Richard Monson-Haefel

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