7.合并導致了多少問題

商場門口豎起了巨大的圣誕樹，上面點綴著五彩繽紛的各種小玩意兒。華燈初上的時候，圣誕樹上的燈也閃亮起來。曉川的心情也不錯。連續兩次，都是星期四就完成了集成工作，不用周末加班嘍。更重要的是，有小小的成就感！

但是說到擔心，還是有的。這個項目是公司最大的項目。項目剛進行了一小半。還不斷有新員工或者其他項目的程序員陸續加入這個項目。可以想見，未來提交會越來越多。很可能在不久的將來，又重新回到需要周末加班的狀態，而且說不定還會再延長，延長到第二個星期去。怪不得當初訂的是每兩周集成一次，而不是每周集成一次！

看來還得繼續改進啊。這次改進，去掉了大約一半的構建問題。得想辦法把剩下的一半也去掉，或者至少是，進一步減少。

跟師傅請教，師傅說，估計是程序員合并的時候不認真。曉川覺得有些道理。更認真一點，當然會更好些。然而，根據曉川的觀察，在合并代碼的時候，絕大部分內容都是自動合并的，因為不同的程序員通常改動的是不同的文件或者一個文件的不同地方。只有碰巧遇到改同一個地方的時候，合并工具才會報合并沖突，曉川才會找程序員來人工合并這一處。而構建失敗，固然可能是因為人工合并的這些地方有問題，也有可能是自動合并的地方沒有合并對，產生了問題。

既然不論是人工還是自動，都可能出錯，那就都再請人檢查一遍好不好呢？曉川設想了一下這個情景，每當自動合并完一個提交后，就過來一個程序員，把自動合并的結果再審一遍。這個主意怎么樣？要不要跟英英討論一下呢？

但是很快曉川意識到這個方法并不可行。現在絕大多數內容的合并都是自動完成的，只有很少是人工完成的，尚且需要半天多的時間。若是全部合并都仔仔細細復審一遍，那就不是再增加一倍的時間的事了。雖然合并之后編譯構建時遇到的錯誤會減少，但是合并階段耗費的時間會延長不知多少，得不償失啊。這招不行。

這樣吧，還是再仔細研究一下，合并時發生了什么事情。第一個提交，不需要合并。第二個提交，要跟第一個提交合并。第三個提交，要跟第一個和第二個的合并的結果進行合并……畫出圖來。如圖2所示。

這么看來，越到后來的提交，要合并的內容就越多，也就越困難。當然，前提是每個人提交的代碼改動量都一樣。而且這是有隨機性的，這只是統計上宏觀看到的結果。

真的是這樣嗎？好像確實有點那個意思，每輪集成，開始的時候，合并沖突會少些，越往后，合并沖突會越多。不過，并沒有理論上分析的那么大的差別。嗯，現實和理論總是不太一樣嘛。就像當年學物理，總是研究剛體、質點之類的理想情況，就是不考慮空氣阻力之類的現實。

那么，回到對代碼合并的分析。會不會是類似空氣阻力的東西，影響了理論推導的結果呢？那么，這里的空氣阻力到底是什么呢？

曉川決定實際調查一下。從本周的第一個提交研究起。按照剛才的理論，第一個提交應該沒有合并問題：就這一個提交，跟誰合并去啊。然而曉川依稀記得，這次第一個提交就遇到了合并沖突。這是怎么一回事呢？

曉川去看版本控制工具里展示的版本樹，仔細研究為什么會有合并。最后終于弄明白了，本周的第一個提交所對應的任務分支，并不是基于最新的基線，而是基于次新的基線，也就是最新基線之前的那個基線。而當曉川從任務分支往集成分支合并的時候，在任務分支上的改動，要跟上一輪集成的所有改動進行合并。如圖3所示。

原來不是因為有空氣阻力，而是理論模型就不適用。

曉川有點兒沮喪，原來是自己弄錯了。不過很快他就意識到，這其實是件好事兒，因為這意味著有可以改進的地方：既然是沒有基于最新基線，多造成了很多合并的問題，那么基于最新基線，就能夠有效地減少合并的問題了！