作者 | 鄭茗蔓
問題的提出
任何復雜的軟件都是團隊工作的產物，所以我們會利用版本控制工具和不同的分支策略來協助團隊的日常開發和交流，mainline開發模式和pull request開發模式（以下簡稱PR）則是最常用到的兩種模式。在開發時選擇哪種模式也成了一個經常被討論的話題。
在疫情時代，遠距離辦公可能會阻礙團隊的交流，PR開發模式也變得越來越流行。一方面PR開發模式可以為代碼開發帶來更好的隔離性，但另一方面，PR開發模式其實是一種更難掌握或者說要求更高的開發模式。比如：審查和合并 PR 的速度至少取決于三個因素：上下文、大小和原子性。此外，PR開發模式對重構不是很友好。因為重構需要高頻率的集成來盡早發現和解決引入的沖突，但在PR開發模式之下是比較難做到的。
相比之下，mainlina開發模式是我更為傾向的一種實踐。首先，它不需要考慮太多額外的因素。開發人員只需要有了“健康”的commit之后，就能與mainline集成，將自己的代碼變更在團隊中可視化。此外，它對重構有很好的支持，因為mainline開發模式本身就支持持續集成。
《Software Configuration Management Patterns》（以下簡稱SCM patterns）一書從軟件配置管理的角度出發，關注那些會影響代碼編寫、功能實現以及代碼更改等日常工作的各個方面，并將其總結成一系列模式。
下面，本文想要從SCM patterns的視角來對比一下mainline開發模式和PR開發模式。
概念的厘清
為了更好地理解這兩種開發模式，以及將其進行對比，有必要先對相關的基本概念以及兩種模式的概念進行簡要的說明。
Codeline和Codeline Policy組合差異決定開發模式的不同
不同的codeline和codeline policy的組合可以形成不同的開發模式。從形式上看，mainline開發模式和PR開發模式的區別，其實是codeline和codeline policy的不同。因此，我們有必要先了解一下這二者的基本概念。
(1) Codeline
codeline其實就是我們常說的branch（Brad Appleton在這里有做說明），在SCM patterns中，codeline的定義如下：
A codeline is a progression of the set of source files and other artifacts
that make up some software component as it changes over time. Every time you
change a file or other artifact in the version control system, you create a
revision of that artifact.
(2) Codeline Policy
codeline policy實際上是對于codeline的使用手冊，為每一條codeline持續運行提供了保障機制，也能夠讓開發人員更加明確的知道：應該將代碼簽入哪個codeline、何時簽入以及在簽入前要運行哪些測試。每個codeline都會相應地有一個codeline policy。
舉個例子：
Development codeline：可以簽入臨時代碼，但相關組件需要是可以構建的。
- Mainline：所有組件必須編譯和鏈接，并通過回歸測試；已完成并且經過測試的新功能可以簽入。
- Release codeline：軟件必須在簽入前構建并通過回歸測試；簽入的代碼僅限于錯誤修復；不得簽入新特性或功能；簽入后，分支被凍結，直到整個QA 周期完成。
總的來說，不同的codeline在不同的項目中，有不同的目的和不同的codeline policy，同時也代表著不同的穩定程度，比如：active development codeline是以快速開發為主，穩定程度足夠開發就好；而release codeline則是一個完全測試，必須保持足夠穩定的codeline。相比之下，release codeline對穩定程度的要求則高很多。
對待mainline和active development line的方式決定兩種開發模式的不同
了解完上面的基本概念之后，下面我們來正式認識一下這兩種不同的開發模式。mainline開發模式和PR開發模式兩者明顯的區別是對待mainline和active development line的方式不同。
(1) Mainline
mainline是一個特殊的codeline，通常它被認為是代表了團隊代碼的當前狀態，用作子分支及其合并的基礎。Martin Flower是這樣描述mainline的：
A single, shared, branch that acts as the current state of the product
需要注意的是mainline是一個codeline，而mainline開發模式是一種development model。
(2) Active development line
active development line是開發人員開發代碼所使用的codeline/branch。但這個codeline的特點是：足夠穩定，能保證開發即可。
(3) Mainline開發模式
mainline開發模式是一種開發人員在mainline上直接進行開發工作的模式。此時，mainline = active development line。在SCM patterns中，作者是這樣描述mainline development model的：
When you are developing a single product release, develop off of a mainline.
A mainline is a “home codeline” that you do all your development on except in
special circumstances.
(4) Pull request 開發模式
PR開發模式則是開發人員在分支上進行開發，然后通過pull request的方式，將分支合并回mainline的一種開發模式。此時，mainline != active development line。
兩種模式的對比
通過上面對兩種開發模式的介紹，我們知道兩者一個明顯的區別是mainline和active development line是否為同一codeline。那么接下來，我想通過集成設計、codeline穩定程度的變化和出發點這三個方面來對兩種開發模式進行對比。
mainline開發模式的集成設計比PR開發模式更為簡單
首先，我們來看codeline和CI設計的問題。
在mainline開發模式中：mainline = active development line
如果需要一個非常穩定的代碼線（stable codeline）以做發布相關或已發布的bug修復等工作的時候，通常會切一個release codeline，此時：
release codeline = stable codeline
在PR開發模式中：feature branch = active development line
注：feature branch在這里指PR所對應的那個分支。
通常，采用PR開發模式其實就是因為mainline需要非常穩定，所以此時：
mainline = stable codeline
因此，這兩種模式對mainline的穩定程度要求是不同的，mainline開發模式對mainline的穩定程度要求是低于PR開發模式的。此外，codeline和CI的聯系是非常緊密的，因為CI的觸發來自于代碼的改變，而代碼的改變來自于特定codeline的commit。所以，在考慮設計我們的CI的時候，同樣也需要考慮如何設計我們的codeline。在SCM patterns的視角下，就是對private workspace的要求不同。
注：圖片來源于《Software Configuration Management Patterns》官方網站
在SCM patterns這張圖中，我們可以看到：private workspace模式的"Complete with"需要integration build和private system build等。而integration build和private system build都需要一系列測試的支持（smoke test、unit test、regression test）。
在mainline開發模式中，開發人員通常是在本地完成開發并通過了codeline policy的提交要求之后，直接將代碼合并到mainline。這個過程中，開發人員會進行頻繁地集成，與mainline的集成通常是在一天之內。由于我們的active development line（mainline）在遠端只有一條，只有當我們進行mainline上的提交的時候，才會觸發CI的運轉。這個時候，我們CI數量等于mainline的數量，其實也就是1條CI。
但在PR開發模式中，開發人員通常是在PR被approve之后，才能對mainline進行集成，因此集成時間通常是好幾天甚至一兩周。這個時候，由于mainline = stable line，但因為feature branch不會對mainline頻繁集成，為了避免feature branch在集成時對stable line引入嚴重的錯誤，因此也會要求feature branch能夠進行更多的測試。但更多的測試也往往意味著更多的開銷，為了讓本地開發高效進行，通常會把build和test放到CI上去。因而在PR開發模式下，通常是一個PR（feature branch/active development line）對應一個CI，這個時候，我們CI數量等于mainline + feature branch的數量。
由此可見，mainline開發模式和PR開發模式對CI的設計是不同，其根本在于codeline的穩定程度影響著對private workspace的要求。
注：把mainline上的代碼持續合并代碼到PR的active development codeline不叫集成，因為集成是pull和push雙方向，Martin Flower的《Patterns for Managing Source Code Branches》文章里也有對此做說明。
mainline開發模式中mainline的穩定程度在持續集成下比PR開發模式更容易發生變化
雖然在mainline開發模式下，mainline = active development line，我們對mainline的穩定程度要求可能不如stable line/release line這么高。但由于頻繁持續的集成，其實mainline/active development line的穩定程度是會發生改變并且趨向于穩定的，而在PR模式下，active development line和mainline的穩定程度則不會一起變化。
在進行對比之前，我們先來看Laura Wingerd在她的書《Practical Perforce》中提出的一種“tofu”模型。“tofu”模型是對codeline的穩定性和質量的一種非正式評估。“tofu”模型會根據以下四個方面來對codeline進行度量：
- How close software is to being released
- How rigorously changes must be reviewed and tested
- How much impact a change has on schedules
- How much a codeline is changing
注：圖片來源于《Practical Perforce》
從圖上我們能看見，release codeline在“tofu”模型上處于最高（firm），通常來說，它不會有太大的變化，也會有嚴格的審查和測試要求，即使是輕微的變化也可能會影響發布計劃。mainline是中等，代碼的更改會需要通過測試，但離發布時間更遠，對發布計劃的影響處于中等。development codeline處于最低（soft），往往會變化迅速，離軟件發布最遠，甚至可能還沒有針對其最新開發的測試。
現在回過頭來看我們這兩種開發模式。
在PR開發模式中，mainline和active development line本身就是兩條codeline，對應的policy也不相同。這里或許會說，我將mainline的policy應用到active development line上，試圖提升active development line在“tofu”模型中的位置，從而間接提升mainline的位置。但其實開發人員始終是在active development line上開發，而非mainline。在active development line沒有被集成到mainline之前，它們始終是兩條codeline。另外，PR開發模式和持續集成也是割裂的，因為PR決定了集成頻率的上限，只有在PR被approve之后才能被集成到mainline中。這種割裂則讓PR開發模式下的mainline難以享受持續集成帶來的好處，比如：更早的發現和解決問題以減少風險。因此，在PR開發模式下，mainline和development line始終會是處于一高（mainline）一低（development line）的狀態，無論development line多么靠近mainline。
但在mainline開發模式中，mainline和active development line是同一條codeline。那么在“tofu”模型中，由于是同一條codeline，這也就意味著將development line/mainline的上限從mainline變成了release line。其次，由于mainline開發模式本身對持續集成就有著很好的支持，其穩定程度也在不斷地集成中趨向于穩定。因為代碼的更改會非常頻繁地集成到mainline中，每一次的合并實際上都是對mainline質量的一次考驗。此外，如果大家能堅持執行“一旦有失敗的commit，所有開發人員的第一優先級是修復錯誤并且不能向mainline提交commit”的理念，那么mainline的質量會趨向于維持在一個較高的水平。
mainline開發模式的出發點比PR開發模式更有利于團隊的長期發展
mainline開發模式和PR開發模式都需要維護代碼質量，但這兩種模式卻又有著不同的出發點。mainline開發模式的出發點是對團隊內開發人員的信任，外加自動化測試套件來維護代碼質量，而PR開發模式的出發點是對陌生開發人員的不信任，從而需要依賴于人工審核來維護代碼質量。
基于不同的出發點，我們也常常能看見二者被使用到不同的項目之中。開源項目和商業項目則是非常典型的例子，不同的項目背景往往也有著不同的組織結構。
開源項目通常是由一些受信任核心成員和不受信任的陌生的開發人員組成。任何陌生人都能接觸到開源項目的源碼，并且通過創建分支，提交PR的形式，對項目進行貢獻。而這些工作，在提交PR之前，項目中的核心成員，對這個人和這個PR完成所需要的時間都是不確定或者說無感知的。PR開發模式很好地解耦了mainline與不受信任開發者之間的依賴關系，既不影響現有軟件的狀態，同時又為想要對軟件作出貢獻的人提供了較低的門檻，并且保證了核心成員對軟件的質量的充分話語權。
商業項目則不同，其通常是由技術領導人和一些開發人員組成。技術領導人對團隊中的開發人員會有一定的了解，并且對一個功能大概會在什么時間內完成也會有相應的計劃，整個團隊通常具有一定的信任度基礎。
因此，PR開發模式常見于開源項目中，而mainline開發模式則常見于商業項目中。
在受信任的團隊氛圍中工作通常既有利于團隊發展，對個人也是一種鼓勵。因此，mainline開發模式對開發人員更為友好。由于團隊信任度并非一成不變，因此在某些時候，使用PR開發模式也不失為一種好方法。
以我個人的經歷舉例：在我剛開始參加工作，成為一名開發人員的時候，當時項目上正好使用PR開發模式，我會經常去找經驗豐富的前輩幫忙看自己的PR。不同于code review，PR往往給予代碼審核者一個更加全面的視角，因為不限于code review的時間，審核人員也能根據自己的思路對整個PR的實現代碼進行詳細的理解，因此，PR的審核相較于code review會更加仔細，對于代碼質量有更加嚴格的控制；而對于被審核者，根據相應的指導和建議進行代碼修改，也能較快地提升代碼的能力。但在加入項目一年多以后，大家對彼此更加了解和信任之后，則采取了mainline開發模式和code review的相對較寬松的方式來對代碼質量進行管理。
結語
盡管在當下隨著遠距離辦公更為普遍，PR開發模式越來越流行，我們仍然需要小心謹慎地使用它。在使用PR開發模式的時候，我們需要合理決定PR的大小，避免PR過大導致將codeline演變成feature branch。同時，團隊需要提出合理的機制以保證PR審核的及時性，否則這種開發模式將極大地阻礙團隊的開發效率。
相比之下，我個人更傾向于mainline開發模式，它在團隊交流上具有天然的優勢。開發人員之間其實是通過集成來進行交流的。怎么快速知道別人的代碼更改會不會影響我，怎么快速知道我的代碼對mainline產生的影響，怎么將自己的代碼放到大家可見的地方以讓別人知道我的更改。這一系列的問題的根本解決方式就是：與mainline快速集成。其次，關于集成的設計成本也較PR開發模式的一個PR（active development line）對應一條CI更低。最后，在談到團隊信任氛圍上，mainline開發模式的出發點是以營造一個相互信任的開發環境，并同時賦予每一個開發人員自由向mainline提交代碼的權利，這是一種更加健康和可持續發展的方式。
