GIT工做流指南系列--gitFlow工做流

GIT工做流

不一樣團隊，不一樣公司，不一樣項目使用的工做流必定是不同的。只有最適合的，沒有最好的，軟件工程沒有銀彈，一樣的GIT工做流也沒有銀彈。

接下來我將用幾篇文章跟你們一塊兒討論一下GIT常見幾種工做流和使用場景。

常見的幾種工做流

• 集中式工做流
• 功能分支工做流
• GitFlow工做流
• Forking工做流
• Pull Requests
• Github Flow工做流
• Gitlab Flow工做流

今天這篇文章先介紹一下大名鼎鼎也是頗受非議的一種工做流GitFlow工做流，爲何先講解gitFlow，由於它是第一個考慮全面，合理功能完備的工做流，甚至於由於其流程的複雜度讓不少人對其很有微詞。同時Github Flow和Gitlab Flow也都是在其基礎上發展出來的。

GitFlow工做流

當在團隊開發中使用版本控制系統時，商定一個統一的工做流程是相當重要的。Git的確能夠在各個方面作不少事情，然而，若是在你的團隊中尚未能造成一個特定有效的工做流程，那麼混亂就將是不可避免的。 git-flow就是當下一個很是流行的工做流。

git-flow是什麼？

它並非什麼新的技術，它只是一套git使用方案，按照這套方案使用git將會得到較好的版本控制體驗。 git-flow只是封裝了一些git命令，讓你在使用的時候能夠更加的方便，即便不使用git-flow你依然能夠經過git命令的組合實現。 gitflow開源項目地址

gitflow經典流程圖

分支類型

• feature分支： 用於功能開發
• develop分支： 用於聚合feature分支開發的功能
• release分支： 用於測試發版
• master 分支： 打上版本TAG長期穩定支持，任何一個tag均可以穩定發佈
• hotfix 分支： 用於修復線上BUG

流程介紹

• 不一樣feature在不一樣feature分支上單獨開發(或測試)。
• 肯定版本號和此版本將要發佈的功能後，將相應featustre分支統一貫develop分支合併，而後拉出新的release預發佈分支。
• release分支做爲持續集成關注的分支，修復bug。
• 待release分支測試驗收經過後，統一貫master分支和develop分支合併，並在master分支打tag。
• 根據tag發佈apk版本。

若線上發現嚴重bug，需走hotfix流程。

• 基於master分支拉出hotfix分支修復線上問題。
• bug修復完成統一貫master和develop分支合併。
• master分支打上新的tag，發佈新版本。

安裝

安裝方式按照不一樣的系統有不一樣的方法，詳細安裝方式能夠參考以下連接

github.com/petervander…

實踐

初始化

你能夠從遠程倉庫clone項目或者本地新建項目

初始化命令

git flow init
複製代碼

該命令會指引你去修改不一樣分支的前綴，建議沒有特別的需求使用默認前綴便可

$ git flow init
Initialized empty Git repository in /Users/tobi/acme-website/.git/
Branch name for production releases: [master] 
Branch name for "next release" development: [develop] 

How to name your supporting branch prefixes?
Feature branches? [feature/] 
Release branches? [release/] 
Hotfix branches? [hotfix/] 
複製代碼

若是你不須要修改默認的分支前綴（大多數狀況）那麼也可使用以下命令進行初始化來跳過詢問過程

git flow init -d
複製代碼

feature分支

當咱們初始化完成以後，就能夠開始一個新功能的開發，開發新功能須要在feature分支上進行，下面就讓咱們建立一個新的叫作rss-feed的feature分支。

git flow feature start rss-feed
複製代碼

這個功能可能須要多人協做才能完成，因此咱們須要把它發佈到遠端（若是是本地建立的項目，請先與遠端倉庫創建聯繫）

git flow feature public rss-feed
複製代碼

這條指令在遠程倉庫新建了一個feature/rss-feed的分支，並將本地ree-feed分支track上述分支，push本地分支代碼。

該命令只能執行一次，當遠程倉庫已經有了相應分支，在執行該命令將會報錯，這個時候只要執行push命令就能夠了。

通過一段時間的努力，咱們跟同事一塊兒協做開發完成了rss-feed分支上的功能，咱們須要把這個feature分支合併到develop分支(可能還有別的feature分支，一塊兒合併到develop)。

git flow feature finish rss-feed
複製代碼

該命令作了如下幾件事

• 切換到develop分支
• 將feature/rss-feed分支merge到develop分支
• 刪除本地feature/rss-feed分支

git flow進行merge操做或者tag操做的時候，會讓打開vim編輯器讓你填寫merge信息或者tag信息（tag信息必須填寫，不然沒法打tag）

若是merge過程發生了衝突，則在第二步merge時終止流程，即不會再刪除本地分支。但當前已處於develop分支，待本地衝突解決並commit後，從新執行git flow feature finish <feature_name>便可完成finish流程。

同步遠程倉庫

• push本地develop分支
• 刪除遠端倉庫feature/rss-feed分支

git push origin develop
git push origin :feature/rss-feed
複製代碼

finish指令的附加參數

• -r mege前先進行rebase操做
• -F merge操做完成後刪除遠程和本地feature分支
• -k 保留feature分支

關於feature分支的討論

不知道你們有沒有這個疑問？feature分支的邏輯功能顆粒度應當是怎樣的？是一個可拆分的大任務？須要多人協做？仍是一個不可拆分的邏輯單元，只能由一我的獨立完成？

個人見解是，每一個人都應該有本身的feature分支，feature分支應當是不可拆分的完整邏輯功能，不該當多人協做；若是可以拆分那就拆成兩個不一樣的feature分支。

這麼作的理由是：

• 若是多人使用同一個feature，勢必會致使publish的衝突，由於只能publish一次。
• finish操做也只能有一我的完成
• feature分支須要時不時的進行pull/push操做
• 每一個分支還必須有一個管理者，整個項目還須要一個最終管理者進行release操做，致使組織結構複雜，而軟件工程開發自己是一個扁平化的結構，扁平化表明了高效率。

由此引起的討論：

• 既然feature分支只是本身在用，是否有必要將feature分支publish到遠程倉庫呢？歡迎你們留言交流。
• 前端如何進行任務分配？模塊化，微服務等概念如何在前端落地？一個項目如何可以拆分紅互不干涉，徹底解耦的幾個部分？若是不能，那麼多人協做的過程當中勢必會產生衝突和功能重複，代碼冗餘，如何避免呢？歡迎你們不吝賜教。

release分支

當項目組的各個成員都完成了本身在本次版本中feature分支的功能開發併合併到develop分支，項目的管理員應當開始release操做。

基於develop分支拉出release分支進行測試，發現bug項目組成員拉取release分支後直接在release分支上進行修改，並提交到遠程倉庫。

下面假設咱們這一次發版的版本號爲v2.0，開始一個release

git flow release start v2.0
複製代碼

此命令會基於本地的develop分支建立一個release/v2.0分支，並切換到這個分支上。

爲了讓其餘協同人員也能看到此分支，須要將其發佈出去。

git flow release publish v2.0
複製代碼

測試完成後就能夠發佈正式版了

git flow release finish v2.0
複製代碼

這一步操做具體流程：

• 切換到master分支
• 執行git fetch檢查更新： 若是遠程倉庫有更新，會停下來並讓你先執行git pull命令（若是有衝突解決衝突並提交，這多是惟一一種直接操做master分支的情形了）, 確保本地master是最新的。
• 若是沒有更新，將release/v2.0分支合併到本地master: 會讓你填寫merge信息，vim的形式（如何操做vim）
• 將release/v2.0分支合併到本地develop
• 刪除本地release/v2.0分支

建議在使用`release finish`命令以前使用git pull更新develop和master代碼，特別是master

若是本地還有未finish的release分支，將不容許使用start指令開啓新的release分支，這一點是對並行發佈的一個限制。

同步到遠程倉庫

git push origin develop
git push origin master
git push origin v2.0
複製代碼

或者

git push origin --all
git push origin --tags
複製代碼

hotfix分支

當咱們的線上版本出現BUG須要緊急修復的時候，流程以下：

假設修復bug的版本號爲v2.0-patch

git flow hotfix start v2.0-patch
複製代碼

hotfix並無public命令，由於BUG通常是比較小且不可分割的邏輯單元，一般是單人在單個工做週期內完成，也不須要跟其餘人協做。

本地完成修復，並測試經過commit以後就能夠執行finish命令

git flow hotfix finish v2.0-patch
複製代碼

該命令執行結果：

Summary of actions:
- Latest objects have been fetched from 'origin'
- Hotfix branch has been merged into 'master'
- The hotfix was tagged 'v2.0-patch'
- Hotfix branch has been back-merged into 'develop'
- Hotfix branch 'hotfix/v2.0-patch' has been deleted
複製代碼

• git fetch 檢查本地與遠端是否up-to-date
• 將v2.0-patch分支合併到master分支
• 生成「v2.0-pathc」標籤
• 將v2.0-patch分支合併到develop分支
• 刪除本地v2.0-patch分支

相關參考資料

GIT工做流指南

GitFlow使用最強指北

什麼是版本控制

版本控制工具的使用基本原則

精準的提交

每次提交都是一個小兒完整的功能或者一個BUG的修復。不該該出現多個功能點一塊提交或者多個BUG一塊兒修復的狀況。若是一旦發現提交的代碼有問題，能夠方便的會滾到改動以前的正確狀態，不會影響到其餘協做者開發進程。

頻繁的提交

儘量頻繁的提交你的改動到遠程倉庫，這樣，能夠避免未來合併代碼的時候產生大量的衝突以致於難以解決。同時，也可讓其餘同事比較快的共享你的改動。

不要提交不完整的功能

若是你正在開發的新功能比較龐大，那麼能夠講這個功能儘量拆分爲幾個邏輯模塊，而且要保證分次提交的邏輯模塊不會影響到整個系統的正確性。若是你只是由於臨時的一些事情須要切到別的分支或者是臨時須要中斷開發（好比說下班）,那麼應該使用Stash儲藏功能來保存你的更改。

提交前進行測試

不要想固然的認爲本身的代碼是正確的，提交以前應該通過充分的測試才能提交，即便是提交到本地倉庫，也應該進行測試，由於這些代碼在將來會被推送到遠程共享給你的同事。

高質量的提交註釋

每次提交都應該包含完整的註釋。團隊成員應當遵循統一的提交規則，通常應當明確的體現出提交的類型以及具體的事情，例如 feat: add message list;

遵循統一的流程規範

Git 能夠支持不少不一樣的工做流程：長期分支、功能分支、合併以及 rebase、git-flow 等等。選擇什麼樣的開發流程要取決以下一些因素：項目開發的類型，部署模式和（多是最重要的）開發團隊成員的我的習慣。無論怎樣，選擇什麼樣的流程都須要獲得全部開發成員的一致承認，而且一直遵循它。