三月 31, 2011
好久沒 PO 文了, 自從開始工作之後越來越少時間能做一些有的沒的事, 包含分享一些東西, 以前看不懂英文, 總覺得為什麼中文的資源總是這麼的少, 現在看的懂英文卻懶的將這些文章一一的翻譯成中文, 看的速度遠比打字的速度還要快, 我這條小鯨魚有時也只能量力而為。
或許很多人都對 SVN 不陌生, 也了解 Version Control 的意涵, 但在實際的開發上, 不僅僅只是要會用這些工具, 而是要能將這些東西合理順暢的在團隊的運作中使用. 並且讓所有人了解, 在我第一次將 SVN 導入開發團隊的工作中也吃了不少苦頭, 絕大多數沒有 Version Control 概念的使用者, 沒有辦法理解這樣的制度, “為什麼要 commit, 要 update 這麼麻煩", “我的程式碼一 update 後就壞了怎麼辦", 更有人是放出大絕招, 把檔案直接砍了用自己原本的蓋回去, …也就是跟別人 conflict 的東西全消失了…只剩他的, 換言之別人的心血也全沒了…。
SVNBook 其實很詳盡, 但內容太多, 所以我只能就有需要的部份翻譯, 讓大家了解概念, however, 剛好今天抽了點時間把 SVNBook 中 Common Branching Patterns 的內容做了一點翻譯, 裡面說明實務上管理 branch 常用的方式.
————————————————————————————————————————-
SVN-常用的分支方式
SVN 中分支與合併有很多不同的用法，這個小節只說明常用的幾種方式。
版本控制經常被用在軟體的開發上，這裡介紹兩個程式設計師所最常使用的方式。如果您目前並非使用 Subversion 做為軟體開發的工具，您可以跳過此節。如果您是個第一次使用版本控管系統的軟體開發者，那就需要認真了解，因此這幾個方式是被有經驗的使用者認為最適合做 為範例案例。以下談到的流程並不僅限用於 Subversion，也可以應用在其他的版本控管系統。
發佈用分支(Release Branches)
大部份的軟體常見的生命週期為: 開發(Code), 測試(Test), 發佈(Release), 循環(Repeat)。在這樣的流程式當中會有兩個問題:
第一, 開發團隊需要開發新的功能的同時, 品管團隊需要持續的測試來維持軟體的穩定性, 新的開發工作並沒有辦法等待軟體測試而中斷。
第二, 開發團隊通常需要去維護舊有已發佈的版本，若在這些舊有的版本中發現問題，客戶會想要立即修正目前的問題，而不想等待其他新的主要功能開發完畢才發佈的版本。
這就是版本控管所能解決的問題，常見的處理流程如下：
- 開發團隊會持續送交(Commit)所有新的開發內容到主幹(Trunk)。
開發團隊每天都會不停持續的修改並且將修改的內容送交到 /trunk: 不論是新功能、問題修正、等等。 - 將主幹複製成為 “發佈用" 分支。
當開發團隊認為軟體已經可以準備發佈 (例如: 1.0 release), 則會從 /trunk 複製一份分支到 /branches/1.0。 - 開發團隊與品管團隊同時進行工作。
品管團隊對要準備發佈的分支進行測試，而開發團隊則繼續開發 (例如: 2.0) 於 /trunk，如果發現有錯誤同時存在兩個分支，則會將問題的修正移植(Ported)到分支，並且繼續開發。在任何時間都可以做這件事，即使開發的流程 已經中止。當最終的測試完成時會將分支凍結(Frozen)停止修改並等待發佈。 - 將分支標記(Tagged)並且正式發佈。
當測試結束，/branches/1.0 會被複製到 /tags/1.0.0 做為備份，並且將已標記的版本打包(Packaged)並正式發佈給客戶。 - 當分支維護一段時間後。
當 2.0 的開發工作一直持續在 /trunk 進行，錯誤的修正也會持續從 /trunk 移植到 /branches/1.0。當累積足夠的錯誤修正，管理者可能會決定發佈 1.0.1 release: 再將 /branches/1.0 複到 /tags/1.0.1，並將 /tags/1.0.1 打包並發佈。
整個流程不停的重複循環，當 2.0 開發工作完成，則會建立新的 2.0 發佈用分支，經過測試、標記直到最後的正式發佈。
幾年過後，儲存庫(Repository)上會有數個以 “維護中(Maintenance)" 的狀態存在的分支(Branch)，並且有數最終已發佈的版本的標記(Tag)。
開發用分支(Feature Branches)
特色分支(Feature Branches)，這邊稱做開發用分支，它是一個暫時的分支，用在複雜的開發工作，可以避免影響 /trunk 的穩定性。與發佈用分支不同的是 (可能需要永久維護)，開發用分支最終會合併(Merge)回到主幹，然後永久移除。
開發用分支的使用時機會隨著專案的管理政策有廣泛影響。
有些專案不使用開發用分支: 這些專案將所有的修改都送交到 /trunk，這樣的好處是管理方式非常的簡單–沒有人需要學習分支(Branching)與合併(Merging)的管理。缺點是主幹的程式碼時常處 於不穩定(Unstable)或不可用(Unusable)的狀態。
也有一些專案會極端的使用分支: 沒有任何的修改會直接送交到主幹，即使修改內容非常微小、使用的分支的時間非常短暫，也會一一經過嚴密的審查(Review)過後才合併到主幹，然後分支才會被移除，這樣的管理方式使主幹擁有異常的穩定性及可用性，但會耗費巨大的開銷。
大多數的專案會採用中傭之道，這些專案堅持使用 /trunk 開發並且測試。但需要大量的修改會使送交的內容不穩定的時候，就會使用開發用分支。良好的經驗法則是先考慮以下的問題：如果開發人員獨立開發數天並一次送 交大量的修改內容 (為了維持 /trunk 在穩定的狀態)，這樣的修改幅度是否會導致管理人員審查? 如果您的答案是 “是"，那麼這些修改應該在開發用分支中進行。因為這樣開發人員能將修改內容逐一送交到分支，而不是一次送交大量的修改內容，如此一來管理人員就能較輕易 的去審查這些修改內容。
最後, 還有一個問題是如何保持開發用分支與主幹的內容保持同步(Sync)。如先前所提到的，讓一個分支獨立開發數週或數月有很大的風險，主幹依然會持續開發，在這樣的情況之下若主幹與分支的開發內容差異過大，那合併分支回主幹的工作將會成為一場惡夢。
這個問題最好的解決方法是定時的合併主幹的修改內容到分支。訂定一個方針: 每週一次, 將最新一週主幹的開發內容合併到分支。
直到一直都有在進行同步的開發用分支要準備合併回主幹。要將分支合併回主幹，需先將最新版本的主幹內容合併至分支，這個動作是確認除了您在分支所修改的內容以外，其餘的部分會與主幹完全相同，最後使用 –reintegrate 參數將分支合併回主幹。
————————————————————————————————————————-
原文的參考文件其實很多, 我隨便挑了一個, 可以參考以下網址的圖片會更容易了解
沒有留言:
張貼留言