2.5　重构的挑战 55

很多团队采用这样的版本控制实践：每个团队成员各自在代码库的一条分支上工作，进行相当大量的开发之后，オ把各自的修改合并回主线分支（这条分支通常叫master或trunk），从而与整个团队分享。常见的做法是在分支上开发完整的功能，直到功能可以发布到生产环境，才把该分支合并回主线。这种做法的拥趸声称，这样能保持主线不受尚未完成的代码侵扰，能保留清晰的功能添加的版本记录，并且在某个功能出问题时能容易地撤销修改。

这样的特性分支有其缺点。在隔离的分支上工作得越久，将完成的工作集成（Integrate）回主线就会越困难。为了减轻集成的痛苦，大多数人的办法是频繁地从主线合并（merge）或者变基（ rebase）到分支。但如果有几个人同时在各自的特性分支上工作，这个办法并不能真正解決问题，因为合并与集成是两回事。如果我从主线合并到我的分支，这只是一个单向的代码移动一一我的分支发生了修改，但主线并没有。而“集成”是一个双向的过程：不仅要把主线的修改拉（pull）到我的分支上，而且要把我这里修改的结果推（push）回到主线上，两边都会发生修改。假如另一名程序员 Rachel正在她的分支上开发，我是看不见她的修改的，直到她将自己的修改与主线集成；此时我就必须把她的修改合并到我的特性分支，这可能需要相当的工作量。其中困难的部分是处理语义变化。现代版本控制系统都能很好地合并程序文本的复杂修改，但对于代码的语义它们一无所知。如果我修改了一个函数的名字，版本控制工具可以很轻松地将我的修改与 Rachel的代码集成。但如果在集成之前，她在自已的分支里新添调用了这个被我改名的函数集成之后的代码就会被破坏。
这学期和小组队友用git协同开发安卓app的时候的确很被这点困扰。之前没意识到这一点，队友也觉得应该在自己的分支上把功能写完再并入master，导致每次把自己的分支merge到master上的时候总要花一些时间专门处理merge conflicts。