概述

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版本團隊內部操作規範

Git Flow 分支管理簡述