# 發布分支 從開發者的角度講，一個自由軟件項目處于連續發布的狀態。開發者通常一直在任何時候都運行最新的可用代碼，因為他們需要定位bug，而且因為他們近距離的接觸項目，可以避開當前特性的不穩定區域。他們通常會每天更新他們軟件的備份，有時一天幾次，當他們檢入變更時，他們有道理認為其他開發者會在24小時內得到。 然而，何時項目應該做出正式的發布？是否僅僅取得某個時刻的快照，打包并交給世界，然后說“3.5.0”？常識告訴我們不是。首先，幾乎沒有一個時刻整個開發樹是干凈和準備好發布的。新開始的特性可能處于不同的狀態。一些人可能檢入了修正bug的主要變更，但是這個變更可能充滿爭議，在發生快照時依然處于辯論階段。在這種情況下，僅僅是延后快照，等待辯論的結束是沒有用的，因為此刻另一個不相關的辯論可能同時發生，那時你就需要等待*那個*辯論的結束。無法保證這個過程的終止。 在任何情況下，使用整個樹的快照作為發布都會干擾正在進行的開發工作，即使整個樹已經進入了可發布狀態。假定快照將會成為“3.5.0”；而下個快照將會是“3.5.1”，會包含在3.5.0版本發現的大多數bug修正。但是如果快照來自同一個樹，開發者在兩個版本之間應該怎么做？他們不可以添加新特性；兼容性政策不允許這種行為。但是，不是每個人都會有激情修改3.5.0的代碼bug。因為人們可能有需要完成的新特性，如果必須在靜候和不想做的事情之間做出選擇，他們會非常憤怒，而原因是項目發布過程要求開發樹保持不自然的靜默。 這個問題的解決方案一直是使用*發布分支*。一個發布分支僅僅是版本控制系統（見[*分支（branch）*](#)）的一個分支，其中預定要發布的代碼已經與開發主線分離。發布分支的概念不僅僅來自自由軟件；許多商業開發組織也會使用它。然后，在商業環境中，發布分支通常被認為是昂貴的—一類正式的“最佳實踐”可以在主開發線針對最終期限的同時，可以讓團隊的每個人分散精力去完成穩定主開發樹的工作。 但是，發布分支在開源項目中是不可或缺的。我經歷過的一些沒有發布分支的項目，但是這樣總會導致一些開發者必須停止下來等待別人—通常是微小的—發布出門的工作。在許多情況下通常結果是不好的。首先，整體開發動力被降低。其次，發布版本可能無法達到必須的質量，因為只有少數人在上面工作，而且他們會急于完成工作，這樣別人才能回來工作。第三，通過設定了一個情形，不同類型的工作不必要的互相干擾了別人的工作，在心理上分割了開發團隊。處于停滯的開發者可能會很樂意為發布分支貢獻*一些*精力，只要他們可以根據自己的日程和興趣做出選擇。但是，沒有這個分支，他們的選擇就變成“今天我可以參與項目嗎？”而不是“我可以為發布工作，還是為主開發線上的新特性的工作？” ### 發布分支的技巧 創建發布分支的確切技巧取決于你的版本控制系統，當然基本概念基本上是相同的。一個分支通常從另一個分支或主干分出。傳統上，主干（trunk）是主要開發進行的地方，不受發布的限制。第一個發布分支，也就是將會變成“1.0”版本的分支是從主干分出的。在CVS中，分支命令類似下面的形式 ~~~ $ cd trunk-working-copy $ cvs tag -b RELEASE_1_0_X ~~~ 或者在Subversion中，類似： ~~~ $ svn copy http://.../repos/trunk http://.../repos/branches/1.0.x ~~~ （這些例子都假設使用三部分的發布號碼系統。因為我無法展示每個版本控制系統中的精確命令，我將會給出CVS和Subversion的例子，希望其他系統中對應的命令可以從中推導出來。） 請注意，我們創建了分支“1.0.x”（包含文字“x”），而不是“1.0.0”。這是因為同一條次要開發線—也就是同一個分支—將會被所有微小版本共用。用于發布的分支穩定化將會在本章后面的[the section called “穩定發布版本”](# "穩定發布版本")描述。這里，我們僅僅關注與版本控制系統的交互和發布過程。當發布分支已經穩定并做好準備，則應該從分支完成標記快照了： ~~~ $ cd RELEASE_1_0_X-working-copy $ cvs tag RELEASE_1_0_0 ~~~ 或 ~~~ $ svn copy http://.../repos/branches/1.0.x http://.../repos/tags/1.0.0 ~~~ 現在標簽代表了項目源代碼樹在1.0.0版本的精確狀態（在較老版本的打包發布和二進制程序被去掉后，如果某人希望獲取時非常有用）。同一開發線的下個微小版本也很可能需要在1.0.x分支上準備，完成后，則增加1.0.1的標簽。再次，重復完成1.0.2等等。當需要完成1.1.x版本時，則從主干再創建一個分支。 ~~~ $ cd trunk-working-copy $ cvs tag -b RELEASE_1_1_X ~~~ 或 ~~~ $ svn copy http://.../repos/trunk http://.../repos/branches/1.1.x ~~~ 維護可以在1.0.x和1.1.x上并行繼續，而版本發布也可以在兩條線上獨立進行。實際上，在兩個不同的開發線上近乎同步的發布版本并不罕見。較舊的系列是保守的站點管理員應該使用的，他們可能不希望在沒有小心準備的情況下做出重大的跳躍到（假設到）1.1。而同時，更多勇于冒險的人會將版本保持在最高的開發線上，以確保他們能獲取最新的特性，即使要冒更大的穩定性風險。 這并不是唯一的發布分支策略，當然。在一些情況下，可能也不是最好的，只是在我參與過的項目中它的表現相當好。盡可以使用有效的策略，但請牢記要點：發布分支的目的是隔離發布工作與日常開發，并給項目一個物理實體用于組織整個發布過程。這個過程將會在下一小節詳細描述。