GitFlow with SourceTree

GitFlow with SourceTree

96 
Thresh0ld 
2017.05.27 14:58* 字數2775 閱讀968 評論0 
網上關於Git-Flow的教程一大堆，哎呀，命令行太多記不住啊。還好有SourceTree，但是好像功能還挺多，不知道什麼時候選擇什麼功能，新版的SourceTree和網上的教程的截圖貌似對應不上。正好我最近也在學習Git-Flow,好記性不如爛筆頭啊，光說不練假把式，我們開始吧。參考教程

一. 首先配置環境

前往SourceTree下載這個免費強大的Git GUI工具。安裝過程略，你需要註冊個SourceTree的賬號。
本文基於SourceTree 2.5.1 mac版,Windows界面差不多。
SourceTree.png
如果你的電腦還未安裝Git的話，首先得安裝Git，同樣安裝過程略。mac用戶建議使用HomeBrew來安裝Git。Windows用戶建議使用安裝包來安裝Git，這樣會自動將git加入到環境變量中。

二. GitFlow

  1. 創建本地和遠程倉庫
創建倉庫.png
image.png
創建好了會自動打開操作窗口

image.png
  1. 做第一次提交（確保至少提交一次到本地倉庫,這樣才會創建master分支）
    如果不提交一次的話，GitFlow就無法初始化，因為其不知道以哪為基線（因為master分支尚未創建）。
    這裡我就在本地的Test文件夾創建個文件，然後在SourceTree的文件狀態裡對這個文件加入索引，再點擊提交。

    image.png

    image.png

    提交後就會發現分支有個master分支了：

    image.png

    如果需要重命名則點擊菜單的“移動”選項
    image.png
  2. 初始化GitFlow
注意：初始化操作需要在團隊每位成員電腦上均進行一次，各配置需保持一致.應由倉庫管理員創建倉庫
按快捷鍵Command+Option+F或者菜單倉庫——GitFlow——初始化倉庫
如果在master分支上沒有做任何提交的話，GitFlow是不會初始化成功的，會報錯如下：
空倉庫初始化git-flow.png

有過提交記錄的master分支可以正常初始化git-flow
image.png

image.png

確定後會出來個develop分支
image.png
  1. 推送到遠程服務器
    注意只需要推送master和develop分支，如果你現在已經創建了feature或release或hotfix分支都不要推送，遠端只需要master和develop.

    image.png
  2. 新增Feature分支（功能）
    老樣子Command+Option+F打開GitFlow菜單，選擇“建立新功能”

    image.png

    輸入新功能名稱:

    image.png

    現在會創建feature，並自動切換到當前feature分支：
    image.png
  3. 在新創建的feature分支中進行開發：
    比如我這裡添加了個新文件：

    image.png

    右擊文件添加索引後提交：

    image.png

    提交後的狀態如下：
    image.png
此處省略一系列的開發提交過程。
  1. 完成feature功能開發

    image.png

    點擊“完成當前版本”按鈕，彈窗如下：

    image.png

    這裡主要講下“在開發分支上進行變基”（rebase）這個勾選框，如果勾上則表示保留在這個feature功能上的提交歷史到develop分支上，不勾選則合併這個功能模塊的提交歷史成一個（Merge某某功能到develop）。默認是不勾選的。一般使用默認選項即可。
    image.png
  2. 發布release分支
release分支總是由develop分支發起
![GitFlow-release分支.png](http://upload-images.jianshu.io/upload_images/1428538-972969c5a2f5cf99.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
填寫版本號.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
  1. 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分支上：

建立新的修復補丁.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

三. 總結

  1. 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分支
  1. 遠程倉庫僅僅應該存在兩個分支，一個是master分支，存放線上（生產環境）版本，這個分支的代碼總是可靠可用的；另一個是develop分支，這個分支用於日常開發。
  2. 本來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分支上了。雖然有這個曲線救國的辦法，但是平時在使用的過程中還是要注意規範，盡量避免這種情況。
  3. feature 分支下可以有多個feature同時在開發，並不影響。feature最終是提交到develop分支上的，release是從develop分支上拉取的，release分支是提交到master分支上的（develop分支不能直接提交到master上），他們幾個並不衝突。允許在仍然有feature在開發的情況下從develop分支拉取到release分支。

    image.png
  4. 如果建立了某個開發功能（feature）或者發布版本（release）分支後，如果不想開發或者發布了，可以先切回到其他分支（比如master或develop分支），然後在要刪除的分支上右擊，選擇“刪除分支”

    image.png
  5. 講下如果線上發布版本的內容或者版本號寫錯了，在網頁上直接刪除即可。

    image.png

    例如我這裡的“fixLoginBug”應該填寫的是“1.0.1”版本號，但是當時提交的時候卻寫錯成修復內容了。
    刪除即可。刪除完了記得會SourceTree裡Pull拉取遠程倉庫的更新內容到本地。
  6. 本文為了演示方便，提交信息以及發布日誌（更新內容）極不規範，實際開發中應該規範提交信息，在大方面做到盡可能的詳細。請參考這個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）每一行最好以常用動詞開頭。
  1. 多人協作的時候，應由倉庫（項目）管理員來創建master分支並在本地初始化好GitFlow後一併將master和develop分支推送到遠程倉庫（master分支默認有寫保護，只有創建者才能寫入推送，其他協作者只能pull拉取）。其他協作者將項目克隆下來，同樣要記得初始化GitFlow，注意配置要保持一致。其他協作者在本地完成feature開發，然後推送到develop分支，由項目管理員來負責發布release分支和發布新版本
關注我的公眾號.jpg
不為五斗米折腰
讚賞支持
     Git
    © 著作權歸作者所有
    舉報文章
    Web note ad 1
    登錄 後發表評論
    评论
    智慧如你，不想发表一点想法咩~
    被以下專題收入，發現更多相似內容
    iOS開發技術
    240git学习笔记
    学习资料pro gitgit - 简明指南Github官方帮助文档Git Community Book 中文版参考廖雪峰GIT教程Learn Git BranchingGit笔记(一)——[commit, checkout]Git笔记(二)——[diff, reset]Gi...
    48
     懒皮
    Git开发流程整理
    Git分支管理 master:主分支，当前分支上的代码随时可以直接发布，并且只能通过Pull Request从其他分支进行合并，而不能直接push修改。当开发告一段落，产生了新的可供发布的代码时，master分支通过Pull Request更新了代码，同时，每一次更新必须添...
    48
     UEUEO
    240什么是GitFlow工作流？
    1.背景介绍 什么是Git工作流？ Git工作流你可以理解为工作中团队成员遵守的一种代码管理方案，在Git中有以下几种工作流方案作为方案指导。 1、集中式工作流 2、功能分支工作流 3、Gitflow工作流 4、Forking工作流 2.知识剖析 1、集中式工作流 这种工作...
    48
     cczhuc
    四中常用的Git工作流比较
    多种多样的工作流使得在项目中实施Git时变得难以选择。这份教程提供了一个出发点，调查企业团队最常见的Git工作流。 阅读的时候，请记住工作流应该是一种规范而不是金科玉律。我们希望向你展示所有工作流，让你融会贯通，因地制宜。 这份教程讨论了下面四种工作流：1.中心化的工作流2...
    48
     Ketine
    240【译文】渐进式学习Git工作流
    每个团队的开发流程各式各样，在工作中如何运用好git并不轻松。这个章节就尝试探究一下在公司团队中最最常用的git工作流。 在你阅读的时候，记住这些开发流主要用来做参考，而不是必须严格遵守，我们只是想展示主流的各种开发工作流让你了解，你应该融汇贯通的运用它们，并形成一个适合你...
    48
     jackiehoo
    240你为什么总是忍不住流口水知道吗？
    我們平常說“流口水”的情況一般包括“見到傾國傾城的美女”，“遇到風流倜儻的帥哥”，“聞到美食撲鼻的香氣”...... 這都是些比喻，雖然我們不排除真的有人如此迷戀，如此瘋狂，或者說猥瑣。但事實上，也真會有讓人“流口水”的可能。真正的“流口水”一般都是在不自覺之間出現，大...
    48
     尚合元健康枕
    自定義View（造輪子）合集
    機緣巧合發現的一份資源，在此感謝原作者（不知道是哪位大神）的分享自定義控件學習https://github.com/GcsSloop/AndroidNote/tree/master/CustomView小良自定義控件合集https://github.com/Mr-Xiao...
    48
     Smart_Arvin
    Swift3.0 數組的基本操作
    初始化數組1.數組的定義2.數組的遍歷3.數組的增-刪-改4.合併數組
    48
     醉裡挑燈看劍
    地鐵
    地鐵上形形色色的人，形形色色的穿戴，形形色色的表情十幾歲的少年很是少見，唯獨有的是我們一行人，帶著些許興奮，也帶著絲絲疲憊。大部分都是社會勞作者，無論是剛踏入社會的大學生，還是久經沙場的的精英，其中都不乏令人欽佩的陽光。但其中的大多數卻是令人恐懼，麻木的目光使我對北京...
    48
     丹柯的故事
    240晚安
    這裡是烏魯木齊不知道你現在正哪裡很想有一天可以牽過你的手帶你踩一遍這裡所有的溫柔
    48
     詩袖

    留言

    張貼留言

    這個網誌中的熱門文章

    Json概述以及python對json的相關操作

    圖片
    什麼是json： JSON(JavaScript Object Notation) 是一種輕量級的數據交換格式。易於人閱讀和編寫。同時也易於機器解析和生成。它基於JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999的一個子集。JSON採用完全獨立於語言的文本格式，但是也使用了類似於C語言家族的習慣（包括C, C++, C#, Java, JavaScript, Perl, Python等）。這些特性使JSON成為理想的數據交換語言。 JSON建構於兩種結構： “名稱/值”對的集合（A collection of name/value pairs）。不同的語言中，它被理解為對象（object），紀錄（record），結構（struct），字典（dictionary），哈希表（hash table），有鍵列表（keyed list），或者關聯數組（associative array）。 值的有序列表（An ordered list of values）。在大部分語言中，它被理解為數組（array）。 這些都是常見的數據結構。事實上大部分現代計算機語言都以某種形式支持它們。這使得一種數據格式在同樣基於這些結構的編程語言之間交換成為可能。 jso官方說 ​​明參見：http://json.org/ Python操作json的標準api庫參考：http://docs.python.org/library/json.html 對簡單數據類型的encoding 和decoding： 使用簡單的json.dumps方法對簡單數據類型進行編碼，例如： import json obj = [[ 1 , 2 , 3 ], 123 , 123.123 , 'abc' ,{ 'key1' :( 1 , 2 , 3 ), 'key2' :( 4 , 5 , 6 )}] encodedjson = json.dumps(obj) print repr (obj) print encodedjson 輸出： [[1, 2, 3], 123, 123.123, 'abc', {'ke...
    閱讀完整內容

    Docker容器日誌查看與清理

    1. 問題 docker容器日誌導致主機磁盤空間滿了。 docker logs -f container_name 劈裡啪啦一大堆，很佔用空間，不用的日誌可以清理掉了。  2. 解決方法 2.1 找出Docker容器日誌 在linux上，容器日誌一般存放在 /var/lib/docker/containers/container_id/ 下面，查看各個日誌文件大小的腳本docker_log_size.sh，內容如下： #!/bin/sh echo "======== docker containers logs file size ========" logs=$(find /var/lib/docker/containers/ -name *-json.log) for log in $logs do ls -lh $log done # chmod +x docker_log_size.sh # ./docker_log_size.sh 2.2 清理Docker容器日誌（治標） 如果docker容器正在運行，那麼使用 rm -rf 方式刪除日誌後，通過 df -h 會發現磁盤空間並沒有釋放。 原因是在Linux或者Unix系統中，通過 rm -rf 或者文件管理器刪除文件，將會從文件系統的目錄結構上解除鏈接（unlink）。 如果文件是被打開的（有一個進程正在使用），那麼進程將仍然可以讀取該文件，磁盤空間也一直被佔用。 正確姿勢是 cat /dev/null > *-json.log ，當然你也可以通過 rm -rf 刪除後重啟docker。 接下來，提供一個日誌清理腳本 clean_docker_log.sh ，內容如下： #!/bin/sh echo "======== start clean docker containers logs ========" logs=$(find /var/lib/docker/containers/ -name *-json.log) for log in $logs d...
    閱讀完整內容

    利用 Keepalived 提供 VIP

    Keepalived 是一種基於 VRRP 協定實現的高可靠 Web 服務方案，用於防止單點故障問題。因此一個 Web 服務運作至少會擁有兩台伺服器執行 Keepalived，一台作為 master，一台作為 backup，並提供一個虛擬 IP（VIP），master 會定期發送特定訊息給 backup 伺服器，當 backup 沒收到 master 訊息時，表示 master 已故障，這時候 backup 會接管 VIP，繼續提供服務，來確保服務的高可靠性。 VRRP VRRP（Virtual Router Redundancy Protocol，虛擬路由器備援協定），是一個提供備援路由器來解決單點故障問題的協定，該協定有兩個重要概念： * VRRP 路由器與虛擬路由器：VRRP 路由器是表示運作 VRRP 的路由器，是一個實體裝置，而虛擬路由器是指由 VRRP 建立的邏輯路由器。一組 VRRP 路由器協同運作，並一起構成一台虛擬路由器，該虛擬路由對外提供一個唯一固定的 IP 與 MAC 位址的邏輯路由器。 * 主控制路由器（master）與備援路由器（backup）：主要是在一組 VRRP 中的兩種互斥角色。一個 VRRP 群組中只能擁有一台是 master，但可以有多個 backup 路由器。 VRRP 協定使用選擇策略從路由器群組挑選一台作為 master 來負責 ARP 與轉送 IP 封包，群組中其他路由器則作為 backup 的角色處理等待狀態。當由於某種原因造成 master 故障時，backup 會在幾秒內成為 master 繼續提供服務，該階段不用改變任何 IP 與 MAC 位址。 Keepalived 節點配置 IP ADDRESS ROLE 172.16.1.101 vip 172.16.1.102 master 172.16.1.103 backup 安裝與設定 這 ubuntu 14.04 LTS Server 中已經內建了 Keepalived 可以透過 apt-get 來安裝： $ sudo apt-get install -y keepalived 也可以透過 source code 進行安裝，流程如下： $ sudo apt-get install build-essential libssl-dev $ wge...
    閱讀完整內容