版本控制的分支策略及初步實踐

2021-09-30 22:30:13 字數 2445 閱讀 5050

這幾天在網上查詢了一些資料,了解到比較常見的版本控制分支策略有三種:不穩定主幹策略、穩定主幹策略、敏捷發布策略。

下面是對這幾種策略的摘錄:

不穩定主幹策略

使用用主幹作為新功能開發主線,分支用作發布。

被廣泛的應用於開源專案。

比較適合諸如傳統軟體產品的開發模式,比如微軟的office等。

bug修改需要在各個分支中合併。

新**在主幹上開發,因此如果主幹不能達到穩定的標準,就不可以進行發布。

這種策略的好處是沒有分支合併的工作量,因此比較簡單。

穩定主幹策略

使用主幹作為穩定版的發布。

bug的修改和新功能的增加,全部在分支上進行。

不同的修改或新功能開發以分支隔離。

分支上的開發和測試完畢以後才合併到主幹。

主幹上的每一次發布都做乙個標籤而不是分支。

每次發布的內容調整起來比較容易。

缺點是分支合併所增加的成本。

敏捷發布策略

敏捷開發模式的專案中廣泛採用,敏捷開發的專案具有固定的發布週期。

為每個task建立分支。

為每個發布建立分支,每個週期內的task分支需要合併到發布分支發布。

在完成發布後,發布分支的功能合併到主幹和尚在進行的任務分支中。

一種穩定主幹策略的變體。

團隊成員要求較高。

團隊當前情況

負責網際網路產品的開發,發布更新較為頻繁。

有固定的發布週期,同時也存在比較多的hotfix。

修改任務通常比較小,改動範圍通常不大,時間通常較短。

不同的功能頁面有不同的小組負責,耦合度相對較低。

團隊目前沒有採用分支策略,開發人員協商進行增量更新,出現錯誤的機率較高。

已使用微軟tfs做為版本控制工具,可以更充分的挖掘使用tfs的分支功能。

我的初步實踐

參考上述策略,結合當前團隊的現狀,我初步設計了下面的版本控制解決方案。

此方案已穩定主幹策略為主結合了一些敏捷發布策略的思路,具體實施方案如下:

1、主幹時刻處於穩定狀態,隨時可以發布。設專門人員對主幹**進行管理,普通開發人員唯讀。

2、為開發任務建立開發分支。常規的可以以小組為單位建立分支,較大的任務可以建立專門的分支。

3、在發布日,從主幹複製乙個測試分支,需要在本發布日發布的各開發分支向此測試分支合併。

4、對測試分支**進行測試,出現bug在測試分支上更改,無誤後發布。

5、測試分支**發布後,合併入主幹,並在主幹上進行標記。

6、對緊急修復(hotfix)的情況,可以從主幹複製出測試分支,在測試分支上進行緊急修改,並在測試後發布,發布後同樣將**合併會主幹,做標記。

7、 hotfix僅限於可以很快解決的小問題,如果更改時間過長,則需採用常規方法完成。

8、如果在測試分支測試過程中需要hotfix工作,則在複製乙個新的測試分支進行hotfix,測試後發布。然後同時合併入原測試分支和主幹,並在主幹上做標記。此過程未在上圖中畫出。

9、測試分支發布後,開發分支可以刪除;測試分支合併入主乾後,測試分支可以定期刪除。

方案的優缺點

方案優點

1、解決了沒有實施分支策略時,**不能經常簽入的問題。

2、主幹**始終處於穩定的狀態隨時可以發布,降低了風險。

3、可以基於乙個完整的測試分支進行測試及發布,而不是以口口相傳的方式增量更新。

方案缺點

1、建立分支、合併分支增加了工作量。考慮實際情況,以及版本控制工具的輔助,增加的工作量應該可以接受。

2、如果某些開發分支工期跨越多個發布週期,修改過於劇烈,合併分支時可能工作量較大。可以考慮分解任務,避免過大的任務出現。

3、在同一時間最好只有乙個測試分支,因此建立測試分支的許可權需要限制,除hotfix場景外應當避免。

***********************************=分割線******************************==

版本控制的分支策略及初步實踐

這幾天在網上查詢了一些資料,了解到比較常見的版本控制 分支策略有三種 不穩定主幹策略 穩定主幹策略 敏捷 發布策略。下面是對這幾種策略的摘錄 不穩定主幹策略 使用用主幹作為新功能開發主線,分支用作發布。被廣泛的應用於開源專案。比較適合諸如傳統軟體產品的開發模式,比如微軟 的office等。bug修改...

版本控制的分支策略及初步實踐

這幾天在網上查詢了一些資料,了解到比較常見的版本控制分支策略有三種 不穩定主幹策略 穩定主幹策略 敏捷發布策略。下面是對這幾種策略的摘錄 不穩定主幹策略 使用用主幹作為新功能開發主線,分支用作發布。被廣泛的應用於開源專案。比較適合諸如傳統軟體產品的開發模式,比如微軟的office等。bug修改需要在...

版本控制的極佳實踐

本文是www.git tower.com總結的使用git的最佳實踐,其中的大部分實踐具有普適性,可用其他版本控制工具svn,cvs等。原文 best practice of version control in git 每次提交的應該是一系列有關聯的變化。例如,修復了兩個不同的bug應該分別提交兩次...