Git Flow 分支管理簡述

概述

Git 是什麼

Git 是一個開源的分佈式版本控制系統，用於敏捷高效地處理任何或小或大的項目。

Git 是 Linus Torvalds 爲了幫助管理 Linux 內核開發而開發的一個開放源碼的版本控制軟件。

Git 與經常使用的版本控制工具 CVS, Subversion 等不一樣，它採用了分佈式版本庫的方式，沒必要服務器端軟件支持。

Git 有哪些特性

• 直接記錄快照，而非差別比較
• 多數操做僅添加操做
• 近乎全部操做都是本地執行
• 時刻保持數據完整性

有關以上特性的詳細解釋，請查看Pro Git的Git基礎章節。

爲何要使用 Git

• 可以對文件版本控制和多人協做開發。
• 擁有強大的分支特性，因此可以靈活地以不一樣的工做流協同開發。
• 分佈式版本控制系統，即便協做服務器宕機，也能繼續提交代碼或文件到本地倉庫，當協做服務器恢復正常工做時，再將本地倉庫同步到遠程倉庫。
• 當團隊中某個成員完成某個功能時，經過pull request操做來通知其餘團隊成員，其餘團隊成員可以review code後再合併代碼。

Git Flow 簡介

　　Git Flow是構建在Git之上的一個組織軟件開發活動的模型，是在Git之上構建的一項軟件開發最佳實踐。

分支約定

　　Git Flow有主分支和輔助分支兩類分支。其中主分支用於組織與軟件開發、部署相關的活動；輔助分支組織爲了解決特定的問題而進行的各類開發活動。

主分支

　　主分支是全部開發活動的核心分支。全部的開發活動產生的輸出物最終都會反映到主分支的代碼中。主分支分爲master分支和develop分支。

master 分支

• master分支存放的是隨時可供在生產環境中部署的穩定版本代碼
• master分支保存官方發佈版本歷史，release tag標識不一樣的發佈版本
• 一個項目只能有一個master分支
• 僅在發佈新的可供部署的代碼時才更新master分支上的代碼
• 每次更新master，都需對master添加指定格式的tag，用於發佈或回滾
• master分支是保護分支，不可直接push到遠程倉master分支
• master分支代碼只能被release分支或hotfix分支合併

develop 分支

• develop分支是保存當前最新開發成果的分支
• 一個項目只能有一個develop分支
• develop分支衍生出各個feature分支
• develop分支是保護分支，不可直接push到遠程倉庫develop分支
• develop分支不能與master分支直接交互

輔助分支

　　輔助分支是用於組織解決特定問題的各類軟件開發活動的分支。輔助分支主要用於組織軟件新功能的並行開發、簡化新功能開發代碼的跟蹤、輔助完成版本發佈工做以及對生產代碼的缺陷進行緊急修復工做。這些分支與主分支不一樣，一般只會在有限的時間範圍內存在。

輔助分支包括：

• 用於開發新功能時所使用的feature分支
• 用於輔助版本發佈的release分支
• 用於修正生產代碼中的缺陷的hotfix分支

　　以上這些分支都有固定的使用目的和分支操做限制。從單純技術的角度說，這些分支與Git其餘分支並無什麼區別，但經過命名，咱們定義了使用這些分支的方法。

feature 分支

使用規範：

• 命名規則：feature/*
• develop分支的功能分支
• feature分支使用develop分支做爲它們的父類分支
• 以功能爲單位從develop拉一個feature分支
• 每一個feature分支顆粒要儘可能小，以利於快速迭代和避免衝突
• 當其中一個feature分支完成後，它會合並回develop分支
• 當一個功能由於各類緣由不開發了或者放棄了，這個分支直接廢棄，不影響develop分支
• feature分支代碼能夠保存在開發者本身的代碼庫中而不強制提交到主代碼庫裏
• feature分支只與develop分支交互，不能與master分支直接交互

　　若有幾個同事同時開發，須要分割成幾個小功能，每一個人都須要從develop中拉出一個feature分支，可是每一個feature顆粒要儘可能小，由於它須要咱們能儘早merge回develop分支，不然衝突解決起來就沒完沒了。同時，當一個功能由於各類緣由不開發了或者放棄了，這個分支直接廢棄，不影響develop分支。

release 分支

使用規範：

• 命名規則：release/*，「*」以本次發佈的版本號爲標識
• release分支主要用來爲發佈新版的測試、修復作準備
• 當須要爲發佈新版作準備時，從develop衍生出一個release分支
• release分支能夠從develop分支上指定commit派生出
• release分支測試經過後，合併到master分支而且給master標記一個版本號
• release分支一旦創建就將獨立，不可再從其餘分支pull代碼
• 必須合併回develop分支和master分支

　　release分支是爲發佈新的產品版本而設計的。在這個分支上的代碼容許作小的缺陷修正、準備發佈版本所需的各項說明信息（版本號、發佈時間、編譯時間等）。經過在release分支上進行這些工做可讓develop分支空閒出來以接受新的feature分支上的代碼提交，進入新的軟件開發迭代週期。

　　當develop分支上的代碼已經包含了全部即將發佈的版本中所計劃包含的軟件功能，而且已經過全部測試時，咱們就能夠考慮準備建立release分支了。而全部在當前即將發佈的版本以外的業務需求必定要確保不能混到release分支以內（避免由此引入一些不可控的系統缺陷）。

　　成功的派生了release分支，並被賦予版本號以後，develop分支就能夠爲「下一個版本」服務了。所謂的「下一個版本」是在當前即將發佈的版本以後發佈的版本。版本號的命名能夠依據項目定義的版本號命名規則進行。

hotfix 分支

使用規範：

• 命名規則：hotfix/*
• hotfix分支用來快速給已發佈產品修復bug或微調功能
• 只能從master分支指定tag版本衍生出來
• 一旦完成修復bug，必須合併回master分支和develop分支
• master被合併後，應該被標記一個新的版本號
• hotfix分支一旦創建就將獨立，不可再從其餘分支pull代碼

　　除了是計劃外建立的之外，hotfix分支與release分支十分類似：均可以產生一個新的可供在生產環境部署的軟件版本。

　　當生產環境中的軟件遇到了異常狀況或者發現了嚴重到必須當即修復的軟件缺陷的時候，就須要從master分支上指定的TAG版本派生hotfix分支來組織代碼的緊急修復工做。

　　這樣作的顯而易見的好處是不會打斷正在進行的develop分支的開發工做，可以讓團隊中負責新功能開發的人與負責代碼緊急修復的人並行的開展工做。

使用規範

全部使用了本規範的項目，必須嚴格規範操做，不然不予以合併代碼、提測、打包上線等後續操做。

基本要求

• 全部commit必須有註釋，內容必須簡潔明瞭的描述本次commit涵蓋了哪些內容。嚴禁註釋內容過於簡單或不能明確表達提交內容的！
• 合理控制提交內容的顆粒度，一次commit含一個獨立功能點。嚴禁一次提交涵蓋多個功能項。
• 正確爲每一個項目設置Git提交用到的user.name和user.email信息，以公司郵箱爲準，不可隨意設置以影響沒法正確識別。 查看當前項目配置信息的命令：git config -l

版本號(tag)

• 版本號(tag)命名規則：主版本號.次版本號.修訂號，如2.1.13。(遵循GitHub語義化版本命名規範)
• 版本號僅標記於master分支，用於標識某個可發佈/回滾的版本代碼
• 對master標記tag意味着該tag能發佈到生產環境
• 對master分支代碼的每一次更新(合併)必須標記版本號
• 僅項目管理員有權限對master進行合併和標記版本號

項目權限

• Git權限分管理員、開發者、瀏覽者三種類型
• 瀏覽者只能瀏覽代碼，無push、pull request等全部寫權限
• 開發者擁有瀏覽、push非主分支、提交pull request工單權限
• 管理員擁有創建和管理Git項目、合併分支和代碼、給master打tag版本號等權限

分支使用

• 每一個Git項目固定含有上述全部分支類型。主分支master和develop是保護分支，只能進行合併請求，均不可直接提交代碼。
• 功能需求或常規Bug修復，請從develop拉取feature分支；線上緊急問題修復，請從master拉去hotfix分支。

代碼提交

• 一個提交就表明解決一個問題
• 大問題適當地分解爲多個小問題，以便每次小型提交都更易於理解
  
  

經常使用命令

WorkSpace:  工做區 

Index/Stage: 暫存區       "git add ." 命令解釋:    把新建立文件(Untracked files 變成 Changes to be commited) 在暫存區域生成了快照，等待被提交

Repository:   本地倉庫   git commit -m "提交到本地倉庫"  (只有暫存區域的文件（即：文件狀態爲「Changes to be committed」）纔會被提交 )

Remote:        遠程倉庫   git pull origin / git push origin  master:master   (推送本地倉庫分支代碼到遠程分支)

註釋格式

• 第1行，標題行，對提交的簡要總結，長度不超過50個字符，用語採用命令式而非過去式
• 第2行，空行
• 第3行開始，正文內容，對改動的詳細介紹），能夠是多行內容，建議每行長度不超過72個字符
• 正文用於解釋是什麼和爲何，而不是如何作
• 若是有對應的issue，則將issue的id或連接放在註釋正文中
• 並不是強制全部提交都要求3行+格式的註釋，但除非標題行內容就能清晰的描述提交內容，不然必須採用3行+的註釋格式

爲何要約定註釋格式？ 1. 加快 Reviewing Code 的過程 2. 幫助咱們寫好 release note 3. 5年後幫你快速想起來某個分支，tag 或者 commit 增長了什麼功能，改變了哪些代碼 4. 讓其餘的開發者在運行 git blame 的時候想跪謝 5. 其餘小夥伴不會出現想抽你的衝動 6. 總之，一個好的提交信息，會幫助你提升項目的總體質量

看看 Linus Torvalds 在Linux項目上寫的提交註釋：https://github.com/torvalds/linux/commits/master以及 Linus Torvalds 關於提交註釋的討論：https://github.com/torvalds/linux/pull/17#issuecomment-5659933

推薦工具

• SourceTree SourceTree集成了Git Flow功能，能簡單方便的操做和實現常規的工做流程。支持OSX和Windows平臺。
• Git Flow 擴展 Git Flow模型提出者nvie寫的Git命令集擴展，提供了極出色的命令幫助以及輸出提示。支持OSX，Linux和Windows平臺。參考：git-flow 備忘清單

參考資料

• 企業級開發：Gitflow Workflow工做流

• 在阿里 咱們如何管理代碼分支

• Git 在團隊中的最佳實踐--如何正確使用Git Flow

• 基於git的源代碼管理模型——git flow
• Git版本控制與工做流
• Git分支管理策略
• 經常使用 Git 命令清單
• git-flow 備忘清單
• 語義化版本 - GitHub起草的版本號命名規範
• 寫好Git Commit信息的7個建議
• 寫出好的 commit message
• 如何設置Git提交註釋模板
• GIT版本團隊內部操做規範