GitFlow with SourceTree
GitFlow with SourceTree
網上關於Git-Flow的教程一大堆，哎呀，命令行太多記不住啊。還好有SourceTree，但是好像功能還挺多，不知道什麼時候選擇什麼功能，新版的SourceTree和網上的教程的截圖貌似對應不上。正好我最近也在學習Git-Flow,好記性不如爛筆頭啊，光說不練假把式，我們開始吧。參考教程
一. 首先配置環境
SourceTree.png
二. GitFlow
- 創建本地和遠程倉庫
創建倉庫.png
image.png
創建好了會自動打開操作窗口
image.png
- 做第一次提交（確保至少提交一次到本地倉庫,這樣才會創建master分支）
如果不提交一次的話，GitFlow就無法初始化，因為其不知道以哪為基線（因為master分支尚未創建）。
這裡我就在本地的Test文件夾創建個文件，然後在SourceTree的文件狀態裡對這個文件加入索引，再點擊提交。image.pngimage.png提交後就會發現分支有個master分支了：image.png
如果需要重命名則點擊菜單的“移動”選項image.png - 初始化GitFlow
注意：初始化操作需要在團隊每位成員電腦上均進行一次，各配置需保持一致.應由倉庫管理員創建倉庫
按快捷鍵Command+Option+F或者菜單倉庫——GitFlow——初始化倉庫
如果在master分支上沒有做任何提交的話，GitFlow是不會初始化成功的，會報錯如下：
如果在master分支上沒有做任何提交的話，GitFlow是不會初始化成功的，會報錯如下：
空倉庫初始化git-flow.png
有過提交記錄的master分支可以正常初始化git-flow
image.png
image.png
確定後會出來個develop分支
image.png
- 推送到遠程服務器
注意只需要推送master和develop分支，如果你現在已經創建了feature或release或hotfix分支都不要推送，遠端只需要master和develop.image.png - 新增Feature分支（功能）
老樣子Command+Option+F打開GitFlow菜單，選擇“建立新功能”image.png輸入新功能名稱:image.png
現在會創建feature，並自動切換到當前feature分支：image.png - 在新創建的feature分支中進行開發：
比如我這裡添加了個新文件：image.png右擊文件添加索引後提交：image.png
提交後的狀態如下：image.png
此處省略一系列的開發提交過程。
- 完成feature功能開發image.png點擊“完成當前版本”按鈕，彈窗如下：image.png
這裡主要講下“在開發分支上進行變基”（rebase）這個勾選框，如果勾上則表示保留在這個feature功能上的提交歷史到develop分支上，不勾選則合併這個功能模塊的提交歷史成一個（Merge某某功能到develop）。默認是不勾選的。一般使用默認選項即可。image.png - 發布release分支
release分支總是由develop分支發起
填寫版本號.png
image.png
研發這個時候應該切回release分支，將這個分支上的代碼編譯然後部署到測試環境中供QA測試，這個時候團隊一方面應該做代碼ReView工作，一方面要響應QA那邊反饋過來的bug，然後在這個release分支上做修復/修改工作。
例如我這裡簡單的提交一下：
例如我這裡簡單的提交一下：
image.png
當QA覺得OK了，代碼ReView也通過了，那麼就可以“完成發布版本”
image.png
打標籤，撰寫發布日誌、更新內容.png
“以此消息打標籤”這裡應該寫詳細的更新內容，比如新增了XXX，修復了XXX，優化了XXX等，不應該像我截圖那樣直接寫個版本號在上面。
image.png
此時應該推送到遠端倉庫完成真正的發布：
image.png
遠端倉庫你應該能看到新發布的：
推送.png
- hotfix 分支（緊急修復線上版本bug）
git-flow假定當前產品線只需要維護一個版本，所以Git-Flow的hotfix總是基於最新的master分支裡的版本來開闢的。如果需要同時維護多個版本，那麼就不應該用master分支了，可以多建幾個分支比如1.x分支，2.x分支,3.x分支，這樣就可以同時維護3個版本線的產品，但是所帶來的維護量就變的很大了。所以建議大家只維護一個版本來做CI（持續集成）
Git-Flow的hotfix分支和release分支有點像，區別在於release分支是由develop分支拉取出來的新分支，而hotfix分支是由master分支拉取出來的新分支，兩者最終都會合併入master和develop分支。只不過hotfix用於生產環境中的緊急修復，需要快速響應和修復，減少Code ReView和QA環節的時間（不是說不做，只是說盡量快點完成這兩個環節，盡量快點修復，否則大批用戶都會受這個bug影響，畢竟是生產環境。）
假如QA同學發現線上版本有個bug需要修復，他應該在Git的工單系統裡把bug詳細敘述了一下
image.png
注意issue後面的#1這是issue的代號。後面可以通過commit信息來關閉這個issue
回到SourceTree，切回到master分支上：
回到SourceTree，切回到master分支上：
建立新的修復補丁.png
image.png
image.png
在這個hotfix上做bug修復，
image.png
如果你確定修復了某個issue，可以在提交信息中寫fix #1或close #1等信息來直接關閉某個issue。
修復完畢後，繼續Command+Option+F打開GitFlow菜單：
image.png
撰寫新版本發佈內容、更新日誌.png
提交推送.png
推送完畢後，我們來看看網頁:
image.png
大家有沒有註意到issue已經被關閉了，在release那裡也能看到新發布的版本。
image.png
三. 總結
- GitFlow有5大分支：master（主幹）、develop（開發）、feature（功能）、release（預發布）、hotfix（熱修復）。這裡說下release分支，其實正名應該叫發布分支，我為什麼叫他預發布分支呢，因為這個release分支並不是真正的發布，他是由develop分支經過多次feature功能迭代後分出來的一個分支，告訴大家這些功能準備的差不多了，可以準備發布了，但是實際上並沒有發布。release分支創建好後，應由QA做測試，研發一起聯調，然後先發佈到測試環境中進行測試，QA如果覺得有問題，可以先提交工單給研發，研發在這個release分支上做小幅度bug修復，如果QA覺得可以使用的時候再由研發完成發布功能，此時release分支上所做的更改會被合併入master和develop分支中,release分支會在合併後被刪除。
- master
>定义：生产环境分支
作用：记录每一个正式发布版本，TAG所在分支
合并关系：允许release\hotfix分支的合并
建立时机：仓库初始化
初始代码来源：仓库创建
* develop
>定义：开发分支
作用：保持最新的开发代码
合并关系：允许feature\release\hotfix分支的合并
建立时机：master创建完成
初始代码来源：master
* release
>定义：发布分支
作用：表示一个正式发布版本(我更倾向于叫他预发布)
合并关系：不允许任何分支合并
建立时机：线上代码满足发布要求
初始代码来源：任意线上commit，推荐使用develop最新commit
完成操作：合并至master/develop、打相应的TAG
* feature
>定义：新功能分支
作用：独立的功能需求
合并关系：不允许任何分支合并
建立时机：需要开发新的功能
初始代码来源：任意线上commit，推荐使用develop最新commit
完成操作：合并至develop分支
* hotfix
>定义：修复BUG分支
作用：用于修复已发布版本BUG
合并关系：不允许任何分支合并
建立时机：发布版本出现BUG
初始代码来源：master(source tree 没有提供历史发布版本的hotfix创建，如需要可手动操作)
完成操作：合并修改内容至master/develop分支
- 遠程倉庫僅僅應該存在兩個分支，一個是master分支，存放線上（生產環境）版本，這個分支的代碼總是可靠可用的；另一個是develop分支，這個分支用於日常開發。
- 本來master分支上的內容不應直接提交（除了第一次初始化GitFlow前需要至少提交一次在master分支上，確保master裡面有內容），master分支總是應該由develop分支發佈到release分支，經過QA測試確認可以上線後（期間可以在release分支上進行小幅bug修復提交更改），再完成發布新版本功能然後合併入master分支（發布成功後release分支會被刪除，在release分支上所做的更改會自動合併到master和develop分支上）。但是如果在GitFlow已經初始化後（develop分支已經有了）不小心在master上直接提交了新的commit，這會導致develop分支上缺少主幹master分支上的內容，這個時候就需要先將master分支推送到遠端，然後本地切回到master分支，然後再使用pull功能從master分支上拉取內容到develop分支（SourceTree會警告正要從未跟踪的分支上拉取內容，點繼續），這樣就把master上所做的更改來回到develop分支上了。雖然有這個曲線救國的辦法，但是平時在使用的過程中還是要注意規範，盡量避免這種情況。
- feature 分支下可以有多個feature同時在開發，並不影響。feature最終是提交到develop分支上的，release是從develop分支上拉取的，release分支是提交到master分支上的（develop分支不能直接提交到master上），他們幾個並不衝突。允許在仍然有feature在開發的情況下從develop分支拉取到release分支。image.png
- 如果建立了某個開發功能（feature）或者發布版本（release）分支後，如果不想開發或者發布了，可以先切回到其他分支（比如master或develop分支），然後在要刪除的分支上右擊，選擇“刪除分支”image.png
- 講下如果線上發布版本的內容或者版本號寫錯了，在網頁上直接刪除即可。image.png例如我這裡的“fixLoginBug”應該填寫的是“1.0.1”版本號，但是當時提交的時候卻寫錯成修復內容了。
刪除即可。刪除完了記得會SourceTree裡Pull拉取遠程倉庫的更新內容到本地。 - 本文為了演示方便，提交信息以及發布日誌（更新內容）極不規範，實際開發中應該規範提交信息，在大方面做到盡可能的詳細。請參考這個commit模板
例如，
fix: Add TimeUnit null check test case in Timed #5231
* Add TimeUnit null check test case in Timed
* Correct ugly formatting in BasicIntQueueDisposable
* Reformatting line
* Add blockingIterable’s negative buffer size fail test,close #5232
* Modify BlockingMultiObserver field’s modfier to private,fix #5231
* Revert style, modifier
* Remove duplicated test case.
* Remove no need annotation and variable
標題總結了此次提交的主要改動的主題（如果此次提交涉及或者修復了某個issue，建議在標題裡用#來引用這個issue，如果是確認修復了這個issue建議在提交信息使用fix #222或者close #222 來自動關閉對應的issue），然後在下面詳情裡每一行闡述具體改動了什麼（或者說為什麼要這麼改）（為了修復XX，增加了XXX，重構了XXX，修改了XXX，移除了XXXX）每一行最好以常用動詞開頭。
- 多人協作的時候，應由倉庫（項目）管理員來創建master分支並在本地初始化好GitFlow後一併將master和develop分支推送到遠程倉庫（master分支默認有寫保護，只有創建者才能寫入推送，其他協作者只能pull拉取）。其他協作者將項目克隆下來，同樣要記得初始化GitFlow，注意配置要保持一致。其他協作者在本地完成feature開發，然後推送到develop分支，由項目管理員來負責發布release分支和發布新版本
關注我的公眾號.jpg
评论
智慧如你，不想发表一点想法咩~
