柚子快報邀請碼778899分享：git flow與分支管理

http://yzkb.51969.com/

git flow與分支管理

一、git flow是什么二、分支管理1、主分支Master2、開發(fā)分支Develop3、臨時性分支功能分支預發(fā)布分支修補bug分支

三、分支管理最佳實踐1、分支名義規(guī)劃2、環(huán)境與分支3、分支圖

四、git flow缺點

一、git flow是什么

Git 作為一個源碼管理系統(tǒng)，不可避免涉及到多人協(xié)作。

協(xié)作必須有一個規(guī)范的工作流程，讓大家有效地合作，使得項目井井有條地發(fā)展下去?！肮ぷ髁鞒?在英語里，叫做"workflow"或者"flow”，原意是水流，比喻項目像水流那樣，順暢、自然地向前流動，不會發(fā)生沖擊、對撞、甚至漩渦。

最早誕生、并得到廣泛采用的一種工作流程，就是 Git flow 。

首先，項目存在兩個長期分支。

主分支master開發(fā)分支develop

前者用于存放對外發(fā)布的版本，任何時候在這個分支拿到的，都是穩(wěn)定的分布版；后者用于日常開發(fā)，存放最新的開發(fā)版。

其次，項目存在三種短期分支。

功能分支（feature branch）補丁分支（hotfix branch）預發(fā)分支（release branch）

一旦完成開發(fā)，它們就會被合并進develop或master，然后被刪除。

二、分支管理

Git只生成一個指向當前版本（又稱"快照"）的指針，因此非?？旖菀子?。但是，太方便了也會產生副作用。如果你不加注意，很可能會留下一個枝節(jié)蔓生、四處開放的版本庫，到處都是分支，完全看不出主干發(fā)展的脈絡。

Vincent Driessen提出了一個分支管理的策略，非常值得借鑒。它可以使得版本庫的演進保持簡潔，主干清晰，各個分支各司其職、井井有條。理論上，這些策略對所有的版本管理系統(tǒng)都適用，下文中Git只是用來舉例而已，如果你不熟悉Git，跳過舉例部分即可。

1、主分支Master

首先，代碼庫應該有一個、且僅有一個主分支。所有提供給用戶使用的正式版本，都在這個主分支上發(fā)布。 Git主分支的名字，默認叫做Master。它是自動建立的，版本庫初始化以后，默認就是在主分支在進行開發(fā)。

2、開發(fā)分支Develop

主分支只用來發(fā)布重大版本，日常開發(fā)應該在另一條分支上完成。我們把開發(fā)用的分支，叫做Develop。 這個分支可以用來生成代碼的最新隔夜版本（nightly）。如果想正式對外發(fā)布，就需要切換到Master分支上對Develop分支進行"合并"（merge）。

// Git創(chuàng)建Develop分支的命令：

git checkout -b develop master

// 將Develop分支發(fā)布到Master分支的命令

# 切換到Master分支　　

git checkout master

# 對Develop分支進行合并　　

git merge --no-ff develop

這里稍微解釋一下，上一條命令的–no-ff參數(shù)是什么意思。默認情況下，Git執(zhí)行"快進式合并"（fast-farward merge），會直接將Master分支指向Develop分支。

fast-farward merge–no-ff

使用–no-ff參數(shù)后，會執(zhí)行正常合并，在Master分支上生成一個新節(jié)點。為了保證版本演進的清晰，我們希望采用這種做法。關于合并的更多解釋，請參考Benjamin Sandofsky的《Understanding the Git Workflow》。

3、臨時性分支

前面講到版本庫的兩條主要分支：Master和Develop。前者用于正式發(fā)布，后者用于日常開發(fā)。其實，常設分支只需要這兩條就夠了，不需要其他了。

但是，除了常設分支以外，還有一些臨時性分支，用于應對一些特定目的的版本開發(fā)。臨時性分支主要有三種：

功能（feature）分支預發(fā)布（release）分支修補bug（fixbug）分支

這三種分支都屬于臨時性需要，使用完以后，應該刪除，使得代碼庫的常設分支始終只有Master和Develop。

功能分支

第一種是功能分支，它是為了開發(fā)某種特定功能，從Develop分支上面分出來的。開發(fā)完成后，要再并入Develop。 功能分支的名字，可以采用feature-*的形式命名。

// 創(chuàng)建一個功能分支：

git checkout -b feature-x develop

// 開發(fā)完成后，將功能分支合并到develop分支：

git checkout develop

git merge --no-ff feature-x

// 刪除feature分支：

git branch -d feature-x

預發(fā)布分支

第二種是預發(fā)布分支，它是指發(fā)布正式版本之前（即合并到Master分支之前），我們可能需要有一個預發(fā)布的版本進行測試。

預發(fā)布分支是從Develop分支上面分出來的，預發(fā)布結束以后，必須合并進Develop和Master分支。它的命名，可以采用release-*的形式。

// 創(chuàng)建一個預發(fā)布分支：

git checkout -b release-1.2 develop

// 確認沒有問題后，合并到master分支：

git checkout master

git merge --no-ff release-1.2

// 對合并生成的新節(jié)點，做一個標簽　　

git tag -a 1.2

// 再合并到develop分支：

git checkout develop

git merge --no-ff release-1.2

// 最后，刪除預發(fā)布分支：

git branch -d release-1.2

修補bug分支

最后一種是修補bug分支。軟件正式發(fā)布以后，難免會出現(xiàn)bug。這時就需要創(chuàng)建一個分支，進行bug修補。

修補bug分支是從Master分支上面分出來的。修補結束以后，再合并進Master和Develop分支。它的命名，可以采用fixbug-*的形式。

// 創(chuàng)建一個修補bug分支：

git checkout -b fixbug-0.1 master

// 修補結束后，合并到master分支：

git checkout master

git merge --no-ff fixbug-0.1

git tag -a 0.1.1

// 再合并到develop分支：

git checkout develop

git merge --no-ff fixbug-0.1

// 最后，刪除"修補bug分支"：

git branch -d fixbug-0.1

三、分支管理最佳實踐

1、分支名義規(guī)劃

分支/tag名命名規(guī)則描述master分支 主分支master，固定不變永遠是可用的、穩(wěn)定的、可直接發(fā)布的版本，不能直接在該分支上開發(fā)。用于遷移feature和hotfix分支，也用于打上線快照r_tag，用于上線feature-xxx 功能開發(fā)分支feature-{name}，以開發(fā)功能模塊命名 不能有大寫字母，多個單詞之間用下劃線替代由RD從master分支遷出，開發(fā)完成后合并到dev分支，提測的時候合并到qa分支，上線集成的時候需要合并到release分支。用于新需求或功能的開發(fā)也用于dev環(huán)境泳道1的部署（非主干泳道的部署，主干泳道只能用master部署）qa 測試主分支qa，固定不變提測分支，qa分支只能由feature做merge合并，不能直接在該分支上開發(fā)，用于QA測試release-xxx 發(fā)布分支release-${yyyyMMdd}，以yyyyMMdd格式命名，如果一天有多個分支后面增加24單位的雙位小時時間yyMMddHHrelease分支是測試完成后，由RD或QA創(chuàng)建，從master遷，并將feature分支merge到release分支。主要是用在預發(fā)環(huán)境集成測試。release-xxx-bug 功能bug修復分支release-${yyyyMMdd}-bug，參考release-xx分支的命名在release上創(chuàng)建分支修復，修復好提測的bug之后合并回release分支hotfix-xxx 緊急bug修改分支hotfix-{name}，以修復bug的名稱命名。不能有大寫字母，多個單詞之間用下劃線替代項目上線之后可能會遇到一些環(huán)境問題需要緊急修復，流程跟release分支相似，修復完成要上線的時候合并master分支b-tag TAGb-{yyyyMMdd}-{name}，不能有大寫字母，多個單詞之間用下劃線替代b-tag從release分支打出，用于灰度上線驗證r-tag TAGr-{yyyyMMdd}-{name}，不能有大寫字母，多個單詞之間用下劃線替代r-tag用于上線的tag，由QA同學創(chuàng)建?；叶壬暇€驗證通過，會將release合并到master分支，從master打出r-taghotfix分支hotfix/{yyyyMMdd}-{bug}，不能有大寫字母，多個單詞之間用下劃線替代用于線上bug的修復，從master分支遷出

2、環(huán)境與分支

固定代碼分支與服務部署環(huán)境的關聯(lián)關系如下表所示。

環(huán)境代碼分支tag備注prodmasterrtag生產環(huán)境，即線上服務，上線應使用從master分支打出的r_tag上線stagingreleasebtagstaging環(huán)境，用master代碼分支和配置進行驗證，上線前的最后檢查testqa無測試環(huán)境，用于支持QA同事做功能測試，部署權限需聯(lián)系接口QA。devfeature無開發(fā)環(huán)境，用于研發(fā)同事之間做接口聯(lián)調、功能測試。

3、分支圖

四、git flow缺點

Git flow的優(yōu)點是清晰可控，缺點是相對復雜，需要同時維護兩個長期分支。大多數(shù)工具都將master當作默認分支，可是開發(fā)是在develop分支進行的，這導致經常要切換分支，非常煩人。

更大問題在于，這個模式是基于"版本發(fā)布"的，目標是一段時間以后產出一個新版本。但是，很多網站項目是"持續(xù)發(fā)布"，代碼一有變動，就部署一次。這時，master分支和develop分支的差別不大，沒必要維護兩個長期分支。

分支太多，所以會出現(xiàn) git log 混亂的局面。具體來說，主要是 git-flow 使用git merge --no-ff來合并分支，在 git-flow 這樣多個分支的環(huán)境下會讓你的分支管理的 log 變得很難看。如下所示，左邊是使用–no-ff 參數(shù)在多個分支下的問題。 所謂–no-ff參數(shù)的意思是——no fast forward的意思。也就是說，合并的方法不要把這個分支的提交以前置合并的方式，而是留下一個 merge 的提交。這是把雙刃劍，我們希望我們的–no-ff能像右邊那樣，而不是像左邊那樣。對此的建議是：只有 feature 合并到 developer 分支時，使用–no-ff 參數(shù)，其他的合并都不使用–no-ff參數(shù)來做合并。另外，還有一個問題就是，在開發(fā)得足夠快的時候，你會覺得同時維護 Master 和 Developer 兩個分支是一件很無聊的事，因為這兩個分支在大多數(shù)情況下都是一樣的。包括 Release 分支，你會覺得創(chuàng)建的這些分支太無聊。而你的整個開發(fā)過程也會因為這么復雜的管理變得非常復雜。尤其當你想回滾某些人的提交時，你就會發(fā)現(xiàn)這事似乎有點兒不好干了。而且在工作過程中，你會來來回回地切換工作的分支，有時候一不小心沒有切換，就提交到了不正確的分支上，你還要回滾和重新提交，等等。

Git Flow 拋棄了 rebase如果你要使用 Git Flow，就得放棄 rebase。rebase 取消了合并提交——也就是可以看到兩個分支合并的地方。由于 Git Flow 的復雜性，你需要可視化跟蹤分支，這意味著如果你想要看到來龍去脈，就不能使用 rebase。

泳道環(huán)境是什么？ ??

柚子快報邀請碼778899分享：git flow與分支管理

http://yzkb.51969.com/

精彩文章