Git多人协作工作流程
前言
之前一直把Git當做個人版本控制的工具使用，現在由于工作需要，需要多人協作維護文檔，所以去簡單了解了下Git多人協作的工作流程，發現還真的很多講解的，而且大神也已經講解得很清楚了，這里就做一個簡單的閱讀筆記和指引，推薦后續希望了解Git多人協作工作流程的小伙伴學習。
后文介紹到的Git工作流有以下幾種：
從第一個看到最后第七個會感覺有種循環在里面，從最開始就只有一個master分支一個遠端倉庫（集中式工作流），然后添加feature分支（功能分支工作流），添加develop、release、hotfix分支（Git Flow 工作流），然后到多個遠端倉庫支持非可信第三方協作（Forking 工作流），然后支持code review等多人討論、問題跟蹤等（Pull Requests 工作流），然后考慮對"持續發布"項目的不友好、刪除develop和release分支以默認master分支的最新代碼就是當前的線上代碼（Github Flow 工作流），然后考慮這種假設很多時候還是不成立、感覺只剩一個master分支太少、為"持續發布"項目增加不同的環境分支如"pre-production"的預生產分支和"production"的生產分支、為"版本發布"項目每個版本拉出一個分支（Gitlab Flow 工作流）。
Git工作流指南
這篇是看了那么多種工作流中，寫得最為全面和詳細的一篇，介紹了上面說的5種工作流，感覺Pull Request可能不能算一種工作流？因為它可以和其他的工作流結合，貫穿所有這幾種工作流始終。
在閱讀的過程中請記住，本文中的幾種工作流是作為方案指導而不是條例規定。在展示了各種工作流可能的用法后，你可以從不同的工作流中挑選或揉合出一個滿足你自己需求的工作流。
集中式工作流
集中式工作流以中央倉庫作為項目所有修改的單點實體。工作流只用到master這一個分支。所有修改提交到這個分支上。
工作流程（簡化版，詳細的特別是第5步需要看原文）：
使用多人協作Git工作流的關鍵，一定是要養成 先pull后push 的節奏，每次想要push之前，一定要 先拉后推。
另一篇文中介紹：
這種工作流比較 適合小團隊，因為小團隊可能不會太多的協作和合流的動作。
功能分支工作流
功能分支工作流以集中式工作流為基礎，不同的是為各個新功能分配一個專門的分支來開發。這樣可以在把新功能集成到正式項目前，用Pull Requests的方式討論變更。
功能分支工作流背后的核心思路是所有的功能開發應該在一個專門的分支，而不是在master分支上。 這個隔離可以方便多個開發者在各自的功能上開發而不會弄亂主干代碼。 另外，也保證了master分支的代碼一定不會是有問題的，極大有利于集成環境。
功能開發隔離也讓pull requests工作流成功可能， pull requests工作流能為每個分支發起一個討論，在分支合入正式項目之前，給其它開發者有表示贊同的機會。 另外，如果你在功能開發中有問題卡住了，可以開一個pull requests來向同學們征求建議。 這些做法的重點就是，pull requests讓團隊成員之間互相評論工作變成非常方便！
功能分支除了可以隔離功能的開發，也使得通過Pull Requests討論變更成為可能。 一旦某個開發者完成一個功能，不是立即合并到master，而是push到中央倉庫的功能分支上并發起一個Pull Request請求，將修改合并到master。 在修改成為主干代碼前，這讓其它的開發者有機會先去Review變更。
Code Review是Pull Requests的一個重要的收益，而Pull Requests則是討論代碼的一個通用方式。 你可以把Pull Requests作為專門給某個分支的討論。這意味著可以在更早的開發過程中就可以進行Code Review。
功能分支工作流比上面的集中工作流多出的兩點亮點：
Git Flow 工作流
Gitflow工作流通過為 功能開發 、 發布準備 和 維護 分配獨立的分支，讓發布迭代過程更流暢。嚴格的分支模型也為 大型項目提供了一些非常必要的結構。
雖然比功能分支工作流復雜幾分，但提供了用于一個健壯的用于管理大型項目的框架。
相對于使用僅有的一個master分支，Gitflow工作流使用兩個分支來記錄項目的歷史。master分支存儲了正式發布的歷史，而develop分支作為功能的集成分支。 這樣也方便master分支上的所有提交分配一個版本號。
每個新功能位于一個自己的分支，這樣可以push到中央倉庫以備份和協作。 但功能分支不是從master分支上拉出新分支，而是使用develop分支作為父分支。當新功能完成時，合并回develop分支。 新功能提交應該從不直接與master分支交互。
從各種含義和目的上來看，功能分支加上develop分支就是功能分支工作流的用法。但Gitflow工作流沒有在這里止步。
一旦develop分支上有了做一次發布（或者說快到了既定的發布日）的足夠功能，就從develop分支上checkout一個發布分支。 新建的分支用于開始發布循環，所以從這個時間點開始之后新的功能不能再加到這個分支上—— 這個分支只應該做Bug修復、文檔生成和其它面向發布任務。 一旦對外發布的工作都完成了，發布分支合并到master分支并分配一個版本號打好Tag。 另外，這些從新建發布分支以來的做的修改要合并回develop分支。
使用一個用于發布準備的專門分支，使得一個團隊可以在完善當前的發布版本的同時，另一個團隊可以繼續開發下個版本的功能。 這也打造定義良好的開發階段（比如，可以很輕松地說，『這周我們要做準備發布版本4.0』，并且在倉庫的目錄結構中可以實際看到）。
常用的分支約定：
用于新建發布分支的分支: develop
用于合并的分支: master
分支命名: release-* 或 release/*
維護分支或說是熱修復（hotfix）分支用于給產品發布版本（production releases）快速生成補丁，這是唯一可以直接從master分支fork出來的分支。 修復完成，修改應該馬上合并回master分支和develop分支（當前的發布分支），master分支應該用新的版本號打好Tag。
為Bug修復使用專門分支，讓團隊可以處理掉問題而不用打斷其它工作或是等待下一個發布循環。 你可以把維護分支想成是一個直接在master分支上處理的臨時發布。
相比于前面集中式工作流（只有1個master分支）和功能分支工作流（1個master和多個feature分支），Git Flow 工作流瞬間增加了3種不同的分支：develop、release、hotfix。當增加這三種分支之后，整個的工作流程變得比較復雜，每種分支的作用也有一點不同。
- master：在前面兩種工作流中，完全作為主分支，發布、維護這唯一的分支，其他的分支（其實也就只有feature分支）都把master分支作父分支而直接交互；而在此工作流中，master分支則是作為歷史分支，存儲了正式發布的歷史，需要為master分支打上版本號Tag。
- develop：它也記錄著項目的歷史，只不過是作為feature分支的集成分支，記錄的是開發過程的歷史。感覺它其實替代了之前兩種工作流的master分支部分功能，在此工作流中，所有的feature分支都把develop作為父分支而直接交互，所有開發過程中的feature分支提交合并，也都是在develop上進行。當然最初的develop分支肯定是從master分支出來的。
- feature：這個分支的作用和在前面兩種工作流中的作用一致，仍然是開發新功能時候使用，只是它的父分支從master分支變成了develop分支。
- release：發布分支，當develop分支開發得差不多了，能夠到發布的時候，就從develop分支上checkout一個發布分支出來，然后感覺應該是重心就圍繞release分支，為發布做準備，從這個時間點開始之后新的功能不能再加到這個分支上—— 這個分支只應該做Bug修復、文檔生成和其它面向發布任務。，如果按照這里理解的話，應該是說直接在release分支上進行一些bug修復和小規模的修改和完善（達不到需要建立分支的程度？感覺如果bug比較大可能會需要建立分支吧，甚至如果更大的bug可能會把release分支又和develop分支合并，繼續在develop上面做開發才行）。而如果release分支的發布工作全部準備好了，則會合并到master分支打上一個tag，同時合并回develop，同時刪除release分支，如果要求code review，這是一個發起 Pull Request 的理想時機，即準備正式發布到master和合并到develop上。 。使得一個團隊可以在完善當前的發布版本的同時，另一個團隊可以繼續開發下個版本的功能。這句話有點點不懂，如果一個團隊在release分支上完善當前的發布版本，另一個團隊只能就著之前并不太完善的develop分支進行下一個版本功能的開發，最后如果從release分支合并回develop時，那就是一個完善的上一個版本和添加了許多新功能的不太完善的版本，感覺可能會產生比較多的沖突，合并分支的時候會比較麻煩。除非新功能等代碼塊模塊化做得很好，可能會比較好一些吧。另外release分支的命名一般也會加上版本號or描述性的名稱，畢竟它也只是一個中間版本，并不是最終的發布版。release分支是清理發布、執行所有測試、更新文檔和其它為下個發布做準備操作的地方，像是一個專門用于改善發布的功能分支。只要創建這個分支并push到中央倉庫，這個發布就是 **功能凍結** 的。任何不在develop分支中的新功能都推到下個發布循環中。
- hotfix：維護分支，好像有些地方把這個hotfix也取做bugfix，它是唯一可以直接從master分支中fork出來的分支，它的父分支是master，而它為發布版本修復補丁之后，馬上合并到master和develop分支，master每次被合并的時候都要用新的版本號打上Tag，合并到develop分支之后，這個hotfix分支就可以刪掉了。
做個小結，整體來說，master、develop是貫穿整個項目始終的永遠不會被刪除的分支，而feature功能分支在功能完成之后就會被合并到develop中，該分支就可以刪掉；而release發布分支也是當發布準備完成后，發布到master，合并到develop后就可以刪掉；而hotfix維護分支更是在修改維護完成之后，發布到master，合并到develop即可刪除。其中release分支和feature分支可以同時進行，通過限定軟件版本實現的功能，在版本范圍內的，就在release中完善，而在版本范圍外的就在新feature功能分支中進行下一個版本的開發，這里存在一個并行開發的流程。
Forking 工作流
Forking工作流是分布式工作流，充分利用了Git在分支和克隆上的優勢。可以安全可靠地管理大團隊的開發者（developer），并能接受不信任貢獻者（contributor）的提交。
不是使用單個服務端倉庫作為『中央』代碼基線，而讓各個開發者都有一個服務端倉庫。這意味著各個代碼貢獻者有2個Git倉庫而不是1個：一個本地私有的，另一個服務端公開的。
主要優勢是，貢獻的代碼可以被集成，而不需要所有人都能push代碼到僅有的中央倉庫中。 開發者push到自己的服務端倉庫，而只有項目維護者才能push到正式倉庫。 這樣項目維護者 可以接受任何開發者的提交，但無需給他正式代碼庫的寫權限。能為 大型、自發性的團隊（包括了不受信的第三方） 提供靈活的方式來安全的協作。
要提交本地修改時，push提交到自己公開倉庫中 —— 而不是正式倉庫中。 然后，給正式倉庫發起一個pull request，讓項目維護者知道有更新已經準備好可以集成了。 對于貢獻的代碼，pull request也可以很方便地作為一個討論的地方。
集成功能到正式代碼庫，維護者pull貢獻者的變更到自己的本地倉庫中，檢查變更以確保不會讓項目出錯， 合并變更到自己本地的master分支， 然后pushmaster分支到服務器的正式倉庫中。 到此，貢獻的提交成為了項目的一部分，其它的開發者應該執行pull操作與正式倉庫同步自己本地倉庫。
『官方』倉庫的叫法只是一個約定，理解這點很重要。 從技術上來看，各個開發者倉庫和正式倉庫在Git看來沒有任何區別。 事實上，讓正式倉庫之所以正式的唯一原因是它是項目維護者的公開倉庫。
各個開發者應該用分支隔離各個功能，就像在功能分支工作流和Gitflow工作流一樣。 唯一的區別是這些分支被共享了。在Forking工作流中這些分支會被pull到另一個開發者的本地倉庫中，而在功能分支工作流和Gitflow工作流中是直接被push到正式倉庫中。
相比前面介紹的工作流只用了一個origin遠程別名指向中央倉庫，Forking工作流需要2個遠程別名 —— 一個指向正式倉庫，另一個指向開發者自己的服務端倉庫。別名的名字可以任意命名，常見的約定是使用origin作為遠程克隆的倉庫的別名 （這個別名會在運行git clone自動創建）， upstream（上游）作為正式倉庫的別名。
保持本地倉庫和正式倉庫的同步更新。
由于開發者應該都在專門的功能分支上工作，pull操作結果會都是快進合并。
開發者要通知項目維護者，想要合并他的新功能到正式庫中。 Bitbucket和Stash提供了Pull Request按鈕，彈出表單讓你指定哪個分支要合并到正式倉庫。 一般你會想集成你的功能分支到上游遠程倉庫的master分支中。
這個工作流實際上就是在功能分支工作流之上引入另一個抽象層。 不是直接通過單個中央倉庫來分享分支，而是把貢獻代碼發布到開發者自己的服務端倉庫中。
感覺這種工作流其實就是Github使用的工作流（但和后文調研發現看到的Github Flow不同）：如果有人想要對某個開源項目做貢獻，就 Fork-Push-Pull Request，維護者審核OK，合并變更提交到正式倉庫。感覺這個工作流最大的優勢就是最初所說的分布式，而且可以接受不可信任的第三方提交代碼，而不會影響到原本的代碼。其次需要注意的一點是，如果是Fork正式倉庫后，要添加功能，一定要自建feature分支進行修改，然后提交Pull Request給維護者，這樣才能夠進行快速合并。
這個工作流和上面3種工作流最大的區別在于遠端的同樣的倉庫有多個，每個開發者都有一個遠端倉庫，而前面三種工作流其實遠端都只有一個倉庫。正如文中所說『官方』倉庫的叫法只是一個約定，理解這點很重要。 從技術上來看，各個開發者倉庫和正式倉庫在Git看來沒有任何區別。 事實上，讓正式倉庫之所以正式的唯一原因是它是項目維護者的公開倉庫。
Pull Requests 工作流
Pull requests是Bitbucket提供的讓開發者更方便地進行協作的功能，提供了友好的Web界面可以在提議的修改合并到正式項目之前對修改進行討論。
開發者向團隊成員通知功能開發已經完成，Pull Requests是最簡單的用法。 開發者完成功能開發后，通過Bitbucket賬號發起一個Pull Request。 這樣讓涉及這個功能的所有人知道要去做Code Review和合并到master分支。
Pull Request遠不止一個簡單的通知，而是為討論提交的功能的一個專門論壇。 如果變更有任何問題，團隊成員反饋在Pull Request中，甚至push新的提交微調功能。 所有的這些活動都直接跟蹤在Pull Request中。
這種分享提交的形式有助于打造一個更流暢的工作流。
當要發起一個Pull Request，你所要做的就是請求（Request）另一個開發者（比如項目的維護者） 來pull你倉庫中一個分支到他的倉庫中。這意味著你要提供4個信息以發起Pull Request： 源倉庫、源分支、目的倉庫、目的分支。
Pull Request可以和功能分支工作流、Gitflow工作流或Forking工作流一起使用。 但一個Pull Request要求 要么分支不同要么倉庫不同，所以不能用于集中式工作流。【因為集中式工作流只有一個master分支一個遠程倉庫……】
基本的過程是這樣的：
開發者在本地倉庫中新建一個專門的分支開發功能。
開發者push分支修改到公開的Bitbucket倉庫中。
開發者通過Bitbucket發起一個Pull Request。
團隊的其它成員review code，討論并修改。
項目維護者合并功能到官方倉庫中并關閉Pull Request。
在功能分支工作流中使用Pull Request：功能分支工作流用一個共享的Bitbucket倉庫來管理協作，開發者在專門的分支上開發功能。 但不是立即合并到master分支上，而是在合并到主代碼庫之前開發者應該開一個Pull Request發起功能的討論。功能分支工作流只有一個公開的倉庫，所以Pull Request的目的倉庫和源倉庫總是同一個。 通常開發者會指定他的功能分支作為源分支，master分支作為目的分支。收到Pull Request后，項目維護者要決定如何做。如果功能沒問題，就簡單地合并到master分支，關閉Pull Request。 但如果提交的變更有問題，他可以在Pull Request中反饋。之后新加的提交也會評論之后接著顯示出來。在功能還沒有完全開發完的時候，也可能發起一個Pull Request。 比如開發者在實現某個需求時碰到了麻煩，他可以發一個包含正在進行中工作的Pull Request。 其它的開發者可以在Pull Request提供建議，或者甚至直接添加提交來解決問題。
在Gitflow工作流中使用Pull Request：Gitflow工作流和功能分支工作流類似，但圍繞項目發布定義一個嚴格的分支模型。 在Gitflow工作流中使用Pull Request讓開發者在發布分支或是維護分支上工作時， 可以有個方便的地方對關于發布分支或是維護分支的問題進行交流。
在Forking工作流中使用Pull Request：在Forking工作流中，開發者push完成的功能到他自己的倉庫中，而不是共享倉庫。 然后，他發起一個Pull Request，讓項目維護者知道他的功能已經可以Review了。在這個工作流，Pull Request的通知功能非常有用， 因為項目維護者不可能知道其它開發者在他們自己的倉庫添加了提交。Pull Request的源倉庫和目標倉庫不是同一個。 源倉庫是開發者的公開倉庫，源分支是包含了修改的分支。 如果開發者要合并修改到正式代碼庫中，那么目標倉庫是正式倉庫，目標分支是master分支。Pull Request也可以用于正式項目之外的其它開發者之間的協作。 比如，如果一個開發者和一個團隊成員一起開發一個功能，他們可以發起一個Pull Request， 用團隊成員的Bitbucket倉庫作為目標，而不是正式項目的倉庫。 然后使用相同的功能分支作為源和目標分支。
如果需要小明以外的人審核批準代碼，可以把這些人填在【Reviewers】文本框中。
Pull Request并不是為了替代任何 基于Git的協作工作流， 而是它們的一個便利的補充，讓團隊成員間的協作更輕松方便。
在后文的其他帖子中有看到只介紹了前面四種工作流，最后的Pull Request感覺被集成到了前面的4種工作流當中，作為一種討論、解決、跟蹤、及時反饋的工具。
企業日常開發模式
在企業開發中，使用 Git 作為版本控制軟件最看重的還是結合公司自己搭建的 Gitlab，將 Code Review 加入打包部署持續集成的流程中，這樣，代碼開發完成，提交測試前，便可以對開發人員提交的代碼進行 Review，發現潛在的問題，及時指導，對于新人來講，也能更快更好的學習。
master：master永遠是線上代碼，最穩定的分支，存放的是隨時可供在生產環境中部署的代碼，當開發活動告一段落，產生了一份新的可供部署的代碼時，發布成功之后，代碼才會由 aone2 提交到 master，master 分支上的代碼會被更新。應用上 aone2 后禁掉所有人的 master的寫權限
develop：保存當前最新開發成果的分支。通常這個分支上的代碼也是可進行每日夜間發布的代碼，只對開發負責人開放develop權限。
feature: 功能特性分支，每個功能特性一個 feature/ 分支，開發完成自測通過后合并入 develop 分支。可以從 master 或者develop 中拉出來。
hotfix: 緊急bug分支修復分支。修復上線后，可以直接合并入master。
develop 作為固定的持續集成和發布分支，并且分支上的代碼必須經過 CodeReview 后才可以提交到 Develop 分支。它的基本流程如下：
每一個需求/變更都單獨從Master上創建一條Branch分支；
用戶在這個Branch分支上進行Codeing活動；
代碼達到發布準入條件后aone上提交Codereview，Codereview通過后代碼自動合并到Develop分支；
待所有計劃發布的變更分支代碼都合并到Develop后，系統再 rebase master 代碼到Develop 分支，然后自行構建，打包，部署等動作。
應用發布成功后Aone會基于Develop分支的發布版本打一個“當前線上版本Tag”基線；
應用發布成功后Aone會自動把Develop分支的發布版本合并回master；
整體感覺如果是企業開發大型項目的話，還是主要參照Git Flow的多分支進行的一些微調，雖然這種工作流比較復雜，但是對于大型項目的管理來說比較有用，而且也適合快速迭代開發。
后面有對開發工作流的一些討論，支持看一下原文，而且里面有一些圖，講解的更為詳細，很不錯。
Git三大特色之WorkFlow(工作流)
這篇介紹了使用較高的3種工作流：Git Flow、Github Flow、Gitlab Flow。里面有一些需要注意的地方：
Git Flow 的作者 Vincent Driessen 非常建議，合并分支的時候，加上 no-ff 參數，這個參數的意思是不要選擇 Fast-Forward 合并方式，而是策略合并，策略合并會讓我們多一個合并提交。這樣做的好處是保證一個非常清晰的提交歷史，可以看到被合并分支的存在。
master 分支每合并一個分支，無論是 hotfix 還是 release ,都會打一個版本標簽。通過箭頭可以清楚的看到分支的開始和結束走向，例如 feature 分支從 develop 開始，最終合并回 develop ，hoxfixes 從 master 檢出創建，最后合并回 develop 和 master，master 也打上了標簽。
里面對Github Flow工作流中的Pull Request和issue tracking有一些介紹，這部分還不是特別有經驗，后面慢慢嘗試使用。
這里對Git Flow & GitHub Flow 的瑕疵進行了分析，然后對GitLab Flow進行了介紹，它基于前兩者的缺點進行了一些優化，感覺這算是比較新的工作流（因為沒有在最上面的那個全的里面被列出來）。主要解決了3個問題：
版本的延遲發布–Prodution Branch：master 分支不夠，于是添加了一個 prodution 分支，專門用來發布版本。
不同環境的部署–Environment Branches & Upstream First：每個環境，都對應一個分支，例如下圖中的 pre-production 和 prodution 分支都對應不同的環境，我覺得這個工作流模型比較適用服務端，測試環境，預發環境，正式環境，一個環境建一個分支。比較適用服務端，測試環境，預發環境，正式環境，一個環境建一個分支。要注意，代碼合并的順序，要按環境依次推送，確保代碼被充分測試過,才會從上游分支合并到下游分支。除非是很緊急的情況，才允許跳過上游分支，直接合并到下游分支。這個被定義為一個規則，名字叫 “upstream first”，翻譯過來是 “上游優先”。
版本發布分支–Release Branches & Upstream First：只有當對外發布軟件的時候，才需要創建 release 分支。在 Git Flow ,版本記錄是通過 master 上的 tag 來記錄。發現問題，創建 hotfix 分支，完成之后合并到 master 和 develop。在 GitLab Flow ，建議的做法是每一個穩定版本，都要從master分支拉出一個分支，比如2-3-stable、2-4-stable等等。發現問題，就從對應版本分支創建修復分支，完成之后，先合并到 master，才能再合并到 release 分支，遵循 “上游優先” 原則。
感覺Gitlab Flow說是解決了前面的兩種工作流的缺點，它的兩種適用場景分別是"持續發布"和"版本發布"的項目；然后搜了下，發現這里是阮一峰大神寫的工作流介紹。里面說：
Git Flow
Git flow的優點是清晰可控，缺點是相對復雜，它是基于"版本發布"的，目標是一段時間以后產出一個新版本。但是，很多網站項目是"持續發布"，代碼一有變動，就部署一次。這時，master分支和develop分支的差別不大，沒必要維護兩個長期分支。
Github Flow
Github flow 是Git flow的簡化版，專門配合"持續發布"。它是 Github.com 使用的工作流程。Github flow 的最大優點就是簡單，對于"持續發布"的產品，可以說是最合適的流程。問題在于它的假設：master分支的更新與產品的發布是一致的。也就是說，master分支的最新代碼，默認就是當前的線上代碼。可是，有些時候并非如此，代碼合并進入master分支，并不代表它就能立刻發布。比如，蘋果商店的APP提交審核以后，等一段時間才能上架。這時，如果還有新的代碼提交，master分支就會與剛發布的版本不一致。另一個例子是，有些公司有發布窗口，只有指定時間才能發布，這也會導致線上版本落后于master分支。上面這種情況，只有master一個主分支就不夠用了。通常，你不得不在master分支以外，另外新建一個production分支跟蹤線上版本。
Gitlab Flow
Gitlab flow 的最大原則叫做"上游優先"（upsteam first），即只存在一個主分支master，它是所有其他分支的"上游"。只有上游分支采納的代碼變化，才能應用到其他分支。對于"持續發布"的項目，它建議在master分支以外，再建立不同的環境分支。比如，"開發環境"的分支是master，"預發環境"的分支是pre-production，"生產環境"的分支是production。開發分支是預發分支的"上游"，預發分支又是生產分支的"上游"。代碼的變化，必須由"上游"向"下游"發展。比如，生產環境出現了bug，這時就要新建一個功能分支，先把它合并到master，確認沒有問題，再cherry-pick到pre-production，這一步也沒有問題，才進入production。只有緊急情況，才允許跳過上游，直接合并到下游分支。對于"版本發布"的項目，建議的做法是每一個穩定版本，都要從master分支拉出一個分支，比如2-3-stable、2-4-stable等等。以后，只有修補bug，才允許將代碼合并到這些分支，并且此時要更新小版本號。
Gitlab Flow官網鏈接
其他資料
Git資源集合：這個是從上面這篇的連接看到的，整合了很多的Git相關的學習資料or資源，可以作為后續的學習方向，很6。
GitFlow工作流常用操作流程：這篇是一個公司編寫的，詳細講了他們公司是怎么使用Git Flow工作流的。這里把 hotfix 直接取名為 bugfix 了，作用還一致的，就是在發布的master分支上進行bug修復。感覺和上面描述的主要不同在于release分支，上面是說用于做發布前的準備，如文檔添加等一些小問題的，這里就直接把release分支作為測試分支了，develop分支開發完成后，直接就在這里做測試，如果發現小bug，就在release分支中進行修復。感覺如果是就是做測試分支了，干嘛不直接叫Test分支好了。不過還是有一些借鑒意義，寫得也比較全面，可以參考。
Git 工作流的一些經驗分享：這篇其實是最先看到的一篇，對前面4種工作流簡單評價了一下，適合簡單概念性的入門，能夠對每種工作流有個大概的認識，然后再去深入看上面的這篇會更容易理解。他后面的Git Flow工作流的實踐簡單看了下，最大的特別是hotfix分支不是從master拉的，而是從develop分支拉取的。release分支用于回歸測試和bug修復，其他的分支功能和Git Flow上面講解的差不多。
Git Flow工作流程：也是只對Git Flow工作流進行了介紹，不過里面寫了分支的命名規范，感覺不錯，可以參考：
主分支名稱：master
主開發分支名稱：develop
標簽（tag）名稱：v.RELEASE，其中”“ 為版本號，“RELEASE”大寫，如：v1.0.0.RELEASE
新功能開發分支名稱：feature-or feature/，其中“” 為新功能簡述，如：feature-item-activity-list
發布分支名稱：release-or release/，其中為版本號，“release”小寫，如：release-1.0.0
master的bug修復分支名稱：hotfix-or hotfix/，其中*為bug簡述，如：hotfix/item-update-bug
總結
看了這么多種Git的工作流，感覺比較核心一些共同的思想點如下：
最后回歸本源：
在閱讀的過程中請記住，本文中的幾種工作流是作為方案指導而不是條例規定。在展示了各種工作流可能的用法后，你可以從不同的工作流中挑選或揉合出一個滿足你自己需求的工作流。
任何工作流程都只是規范or標準or推薦，但是并不一定適用于所有的項目、所有的場景、所有的開發人員，針對不同的情況，需要靈活調整。
轉載于:https://www.cnblogs.com/Chayeen/p/9989628.html
總結
以上是生活随笔為你收集整理的Git多人协作工作流程的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 站立会议（11月19日）
- 下一篇： BigDecimal的用法