Git基本命令和GitFlow工做流

本篇博客講解了git的一些基本的團隊協做命令，和GitFlow工做流指南

git 團隊協做的一些命令

• 1.開分支

git branch 新分支名
例如，在master分支下，新開一個開發分支：
git branch dev

• 2.切換到新分支

git checkout 分支名
例如，在master分支下，切換到新開的dev：
git checkout dev

• 3.開分支和切換分支合併到一個命令

git checkout -b 新分支名
例如，新開一個開發分支，並當即切換到該分支：
git checkout -b dev

• 4.切換回原分支

git checkout 原分支名
例如，切換回master
git checkout master
注意：當前分支有修改，還未commit的時候，會切換失敗，應當先commit，但能夠不用push

• 5.合併分支

git merge 須要合併的分支名
例如，剛剛已經切換回master，如今須要合併dev的內容：
git merge dev
建議在GitLab(或者其餘git系統)上面建立merge request的形式來進行分支的合併和代碼審覈。

• 6.查看本地分支列表

git branch -a
前面帶remotes/origin 的，是遠程分支

• 7.查看遠程分支列表

git branch -r

• 8.向遠程提交本地新開的分支

git push origin 新分支名
例如，剛剛在master下新開的dev分支：
git push origin dev

• 9.刪除遠程分支

git push origin :遠程分支名
例如，刪除剛剛提交到遠程的dev分支：
git push origin :dev

• 10.刪除本地分支

git branch 分支名稱 -d
例如，在master分支下，刪除新開的dev分支：
git branch dev -d
注意：若是dev的更改，push到遠程，在GitLab(或者其餘git系統)上面進行了merge操做，可是本地master沒有pull最新的代碼，會刪除不成功，能夠先git pull origin master，或者強制刪除
git branch dev -D

• 11.更新分支列表信息

git fetch -p

• 12.TortoiseGit(烏龜git)

  不能否認，在windows下，這個是個不錯的工具。無論你是命令行新手仍是重度使用者，我以爲均可以嘗試一下。

Git工做流指南：Gitflow工做流

在你開始閱讀以前，請記住：流程應被視做爲指導方針，而非「鐵律」。咱們只是想告訴你可能的作法。所以，若是有必要的話，你能夠組合使用不一樣的流程

Gitflow工做流定義了一個圍繞項目發佈的嚴格分支模型。雖然比功能分支工做流複雜幾分，但提供了用於一個健壯的用於管理大型項目的框架。

Gitflow工做流沒有用超出功能分支工做流的概念和命令，而是爲不一樣的分支分配一個很明確的角色，並定義分支之間如何和何時進行交互。除了使用功能分支，在作準備、維護和記錄發佈也使用各自的分支。固然你能夠用上功能分支工做流全部的好處：Pull Requests、隔離實驗性開發和更高效的協做。

工做方式

Gitflow工做流仍然用中央倉庫做爲全部開發者的交互中心。和其它的工做流同樣，開發者在本地工做並push分支到要中央倉庫中。

歷史分支

相對使用僅有的一個master分支，Gitflow工做流使用2個分支來記錄項目的歷史。master分支存儲了正式發佈的歷史，而develop分支做爲功能的集成分支。這樣也方便master分支上的全部提交分配一個版本號。

剩下要說明的問題圍繞着這2個分支的區別展開。

功能分支

每一個新功能位於一個本身的分支，這樣能夠push到中央倉庫以備份和協做。但功能分支不是從master分支上拉出新分支，而是使用develop分支做爲父分支。當新功能完成時，合併回develop分支。新功能提交應該從不直接與master分支交互。

注意，從各類含義和目的上來看，功能分支加上develop分支就是功能分支工做流的用法。但Gitflow工做流沒有在這裏止步。

發佈分支

一旦develop分支上有了作一次發佈（或者說快到了既定的發佈日）的足夠功能，就從develop分支上fork一個發佈分支。新建的分支用於開始發佈循環，因此從這個時間點開始以後新的功能不能再加到這個分支上 —— 這個分支只應該作Bug修復、文檔生成和其它面向發佈任務。一旦對外發布的工做都完成了，發佈分支合併到master分支並分配一個版本號打好Tag。另外，這些重新建發佈分支以來的作的修改要合併回develop分支。

使用一個用於發佈準備的專門分支，使得一個團隊能夠在完善當前的發佈版本的同時，另外一個團隊能夠繼續開發下個版本的功能。
這也打造定義良好的開發階段（好比，能夠很輕鬆地說，『這周咱們要作準備發佈版本4.0』，而且在倉庫的目錄結構中能夠實際看到）。

經常使用的分支約定：

用於新建發佈分支的分支: develop

用於合併的分支: master

分支命名: release-* 或 release/*

維護分支

維護分支或說是熱修復（hotfix）分支用於生成快速給產品發佈版本（production releases）打補丁，這是惟一能夠直接從master分支fork出來的分支。修復完成，修改應該立刻合併回master分支和develop分支（當前的發佈分支），master分支應該用新的版本號打好Tag。

爲Bug修復使用專門分支，讓團隊能夠處理掉問題而不用打斷其它工做或是等待下一個發佈循環。你能夠把維護分支想成是一個直接在master分支上處理的臨時發佈。

示例

下面的示例演示本工做流如何用於管理單個發佈循環。假設你已經建立了一箇中央倉庫。

建立開發分支

第一步爲master分支配套一個develop分支。簡單來作能夠本地建立一個空的develop分支，push到服務器上：

git branch develop
git push -u origin develop

之後這個分支將會包含了項目的所有歷史，而master分支將只包含了部分歷史。其它開發者這時應該克隆中央倉庫，建好develop分支的跟蹤分支：

git clone ssh://user@host/path/to/repo.git
git checkout -b develop origin/develop

如今每一個開發都有了這些歷史分支的本地拷貝。

工程師A和工程師B開始開發新功能

這個示例中，工程師A和工程師B開始各自的功能開發。他們須要爲各自的功能建立相應的分支。新分支不是基於master分支，而是應該基於develop分支：

git checkout -b some-feature develop

他們用老套路添加提交到各自功能分支上：編輯、暫存、提交：

git status
git add
git commit

工程師A完成功能開發

添加了提交後，工程師A以爲她的功能OK了。若是團隊使用Pull Requests，這時候能夠發起一個用於合併到develop分支。不然她能夠直接合併到她本地的develop分支後push到中央倉庫：

git pull origin develop
git checkout develop
git merge some-feature
git push
git branch -d some-feature

第一條命令在合併功能前確保develop分支是最新的。注意，功能決不該該直接合併到master分支。衝突解決方法和集中式工做流同樣。

工程師A開始準備發佈

這個時候工程師B正在實現他的功能，工程師A開始準備她的第一個項目正式發佈。像功能開發同樣，她用一個新的分支來作發佈準備。這一步也肯定了發佈的版本號：

git checkout -b release-0.1 develop

這個分支是清理髮布、執行全部測試、更新文檔和其它爲下個發佈作準備操做的地方，像是一個專門用於改善發佈的功能分支。

只要工程師A建立這個分支並push到中央倉庫，這個發佈就是功能凍結的。任何不在develop分支中的新功能都推到下個發佈循環中。

工程師A完成發佈

一旦準備好了對外發布，工程師A合併修改到master分支和develop分支上，刪除發佈分支。合併回develop分支很重要，由於在發佈分支中已經提交的更新須要在後面的新功能中也要是可用的。另外，若是工程師A的團隊要求Code Review，這是一個發起Pull Request的理想時機。

git checkout master
git merge release-0.1
git push
git checkout develop
git merge release-0.1
git push
git branch -d release-0.1

發佈分支是做爲功能開發（develop分支）和對外發布（master分支）間的緩衝。只要有合併到master分支，就應該打好Tag以方便跟蹤。

git tag -a 0.1 -m "Initial public release" master
git push --tags

Git有提供各類勾子（hook），即倉庫有事件發生時觸發執行的腳本。能夠配置一個勾子，在你push中央倉庫的master分支時，自動構建好對外發布。

最終用戶發現Bug

對外發布後，工程師A回去和工程師B一塊兒作下個發佈的新功能開發，直到有最終用戶開了一個Ticket抱怨當前版本的一個Bug。爲了處理Bug，工程師A（或工程師B）從master分支上拉出了一個維護分支，提交修改以解決問題，而後直接合並回master分支：

git checkout -b issue-#001 master

Fix the bug

git checkout master
git merge issue-#001
git push

就像發佈分支，維護分支中新加這些重要修改須要包含到develop分支中，因此工程師A要執行一個合併操做。而後就能夠安全地刪除這個分支了：

git checkout develop
git merge issue-#001
git push
git branch -d issue-#001

最後

Git是一個不錯的版本管理工具，但也僅僅是工具。記住，這裏演示的工做流只是可能用法的例子，而不是在實際工做中使用Git不可違逆的條例。因此不要畏懼按本身須要對工做流的用法作取捨。不變的目標就是讓Git爲你所用。

參考資料

1. Comparing Workflows https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow/
2. Git 版本控制系統 http://ihower.tw/git/index.html