SourceTree 實現 git flow 流程

爲何使用 git 和 git flow，這篇文章 深刻理解學習Git工做流 的內容相信可以給你一個完整的答案。

• 咱們以使用SVN的工做流來使用git有什麼不妥？
• git 方便的branch在哪裏，團隊多人如何協做？衝突了怎麼辦？如何進行發佈控制？
• 經典的master-發佈、develop-主開發、hotfix-不過修復如何避免代碼不通過驗證上線？
• 如何在github上面與他人一塊兒協做，star-fork-pull request是怎樣的流程？

這篇文章分爲兩部分，一部分引用 深刻理解學習Git工做流 文章中的 git flow 工做流內容，一部分是使用 SourceTree 中的 git flow 工具來實現可視化的 git flow 流程管理，避免咱們在使用 git 命令時遇到的坑。並且 SourceTree 的全部可視化操做都會展現相應的執行命令。

SourceTree Win10 安裝過程及配置

Gitflow 工做流

Gitflow工做流經過爲功能開發、發佈準備和維護分配獨立的分支，讓發佈迭代過程更流暢。嚴格的分支模型也爲大型項目提供了一些很是必要的結構。

這節介紹的Gitflow工做流借鑑自在nvie的Vincent Driessen。

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

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

2.3.1 工做方式

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

2.3.2 歷史分支

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

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

2.3.3 功能分支

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

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

2.3.4 發佈分支

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

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

經常使用的分支約定：

用於新建發佈分支的分支: develop
用於合併的分支: master 分支命名: release-* 或 release/*

2.3.5 維護分支

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

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

2.3.6 示例

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

建立開發分支

第一步爲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

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

小紅和小明開始開發新功能

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

git checkout -b some-feature develop

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

git status
git add <some-file>
git commit

小紅完成功能開發

添加了提交後，小紅以爲她的功能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分支。
衝突解決方法和集中式工做流同樣。

小紅開始準備發佈

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

git checkout -b release-0.1 develop

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

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

小紅完成發佈

一旦準備好了對外發布，小紅合併修改到master分支和develop分支上，刪除發佈分支。合併回develop分支很重要，由於在發佈分支中已經提交的更新須要在後面的新功能中也要是可用的。
另外，若是小紅的團隊要求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

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

git checkout -b issue-#001 master # Fix the bug git checkout master git merge issue-#001 git push

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

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

到了這裏，希望你對集中式工做流、功能分支工做流和Gitflow工做流已經感受很溫馨了。
你應該也牢固的掌握了本地倉庫的潛能，push/pull模式和Git健壯的分支和合並模型。

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

---

SourceTree 實現 git flow

經過文章《SourceTree Win10 安裝過程及配置》 正確安裝 SourceTree 以及管理示例源碼，界面以下。

初始化 Git flow

點擊右上角的 「Git 工做流」 ，初次會提示咱們 「使用 Git Flow 來初始化此倉庫」，已經幫助咱們預約義好了一些配置，咱們只須要點擊 「肯定」 按鈕便可。

點擊「肯定」按鈕後，咱們會發現 SourceTree 爲咱們自動建立了 develop 分支，而且切換到了 develop 分支。

Git flow: 創建新功能

繼續點擊右上角的 「Git 工做流」 ，此次會提示咱們選擇具體的下一個流程動做，這裏咱們演示一個 「創建新的功能」 流程。

點擊 「建議新的功能」 ，會讓咱們對即將要開發的功能進行命名（名稱請使用英文），這裏咱們輸入 simple-git-flow，點擊肯定按鈕，會自動幫助咱們建立 feature/simple-git-flow 分支，並切換到該分支上。

同時咱們也能看到 SourceTree 幫助咱們執行了什麼命令來達到這樣的效果。

已經自動切換到 feature/simple-git-flow 分支。

提交代碼

此時咱們能夠在分支上開發咱們的新功能，能夠在分支上管理代碼，而不影響到其餘同事的開發工做。

爲了簡單演示，咱們修改下 readme.md 的內容以下：

在 SourceTree 界面，咱們須要在 未暫存文件 區域選中 readme.md 並點擊 暫存所選 按鈕，此時 readme.md 文件會進入到 已暫存文件 區域。只有 已暫存文件 的文件會進行 提交操做 。

在下方的空白區域輸入本次提交的說明：a simple git flow 後點擊提交按鈕，就會提交源碼。

以下圖所示：能夠看到剛剛提交的代碼記錄

完成新功能開發

通過不斷的代碼完善，而且通過單元測試後，代碼已經完成後，此時就能夠完成 新功能的開發 ，繼續點擊 Git 工做流

點擊 「完成功能」，默認會以下圖所示，在正常的開發流程下，咱們不須要更改任何設置，直接點擊肯定便可。

SourceTree 展現所執行的命令及結果。

完成後，咱們會發現 feature/simple-git-flow 分支已經不見了，同時在 develop 分支上多了一個 a simple git flow 的提交信息。

至此整個 「建議新功能」 的 git flow 流程就完畢了。

總結

實際開發過程當中，會遇到各類狀況，沒法經過簡短的文章來講明全部的狀況，具體須要在實踐過程當中不斷學習。

再次總結下爲何要使用 SourceTree

1. 下降入門門檻。不少應屆生並不知道版本管理工具和 git，經過可視化工具，能夠避免初學者在使用過程當中由於不熟悉命令而產生的問題。
2. 使用 SourceTree 的全部操做，都會展現響應的執行命令，也能讓初學者瞭解到具體的操做是經過什麼命令來實現的。
3. 在徹底不熟悉命令的狀況下，也能夠經過 SourceTree 來參與團隊協做開發。

而且在咱們的 Centos 服務器部署中，咱們使用 docker 來管理版本和發佈，也基本用不到複雜的 git 命令，對於初學者的快速入門 SourceTree 足夠了。