前言

之前一直把Git當(dāng)做個人版本控制的工具使用，現(xiàn)在由于工作需要，需要多人協(xié)作維護(hù)文檔，所以去簡單了解了下Git多人協(xié)作的工作流程，發(fā)現(xiàn)還真的很多講解的，而且大神也已經(jīng)講解得很清楚了，這里就做一個簡單的閱讀筆記和指引，推薦后續(xù)希望了解Git多人協(xié)作工作流程的小伙伴學(xué)習(xí)。
后文介紹到的Git工作流有以下幾種：

集中式工作流

功能分支工作流

Git Flow 工作流

Forking 工作流

Pull Requests 工作流

Github Flow 工作流

Gitlab Flow 工作流

從第一個看到最后第七個會感覺有種循環(huán)在里面，從最開始就只有一個master分支一個遠(yuǎn)端倉庫（集中式工作流），然后添加feature分支（功能分支工作流），添加develop、release、hotfix分支（Git Flow 工作流），然后到多個遠(yuǎn)端倉庫支持非可信第三方協(xié)作（Forking 工作流），然后支持code review等多人討論、問題跟蹤等（Pull Requests 工作流），然后考慮對"持續(xù)發(fā)布"項目的不友好、刪除develop和release分支以默認(rèn)master分支的最新代碼就是當(dāng)前的線上代碼（Github Flow 工作流），然后考慮這種假設(shè)很多時候還是不成立、感覺只剩一個master分支太少、為"持續(xù)發(fā)布"項目增加不同的環(huán)境分支如"pre-production"的預(yù)生產(chǎn)分支和"production"的生產(chǎn)分支、為"版本發(fā)布"項目每個版本拉出一個分支（Gitlab Flow 工作流）。

Git工作流指南

這篇是看了那么多種工作流中，寫得最為全面和詳細(xì)的一篇，介紹了上面說的5種工作流，感覺Pull Request可能不能算一種工作流？因為它可以和其他的工作流結(jié)合，貫穿所有這幾種工作流始終。

在閱讀的過程中請記住，本文中的幾種工作流是作為方案指導(dǎo)而不是條例規(guī)定。在展示了各種工作流可能的用法后，你可以從不同的工作流中挑選或揉合出一個滿足你自己需求的工作流。

集中式工作流

集中式工作流以中央倉庫作為項目所有修改的單點實體。工作流只用到master這一個分支。所有修改提交到這個分支上。

工作流程（簡化版，詳細(xì)的特別是第5步需要看原文）：

管理者先在遠(yuǎn)端建立一個倉庫，即為中央倉庫，只有一個默認(rèn)的master分支

其他開發(fā)者clone遠(yuǎn)端中央倉庫到自己本地的倉庫中

開發(fā)者A在本地修改代碼，提交到自己本地倉庫中； 開發(fā)者B在本地修改代碼，提交到自己本地倉庫中……

當(dāng)開發(fā)者A代碼修改完成，測試覺得沒問題了，push到中央倉庫中，成功

之后開發(fā)者B修改完成，如果直接push到中央倉庫中，就會push失敗；他需要先從遠(yuǎn)端pull最新的中央倉庫版本到本地倉庫中，再重新push，這里可能會需要解決沖突，解決沖突之后，再進(jìn)行push即可成功。

使用多人協(xié)作Git工作流的關(guān)鍵，一定是要養(yǎng)成 先pull后push 的節(jié)奏，每次想要push之前，一定要 先拉后推。
另一篇文中介紹：

這種工作流比較 適合小團隊，因為小團隊可能不會太多的協(xié)作和合流的動作。

功能分支工作流

功能分支工作流以集中式工作流為基礎(chǔ)，不同的是為各個新功能分配一個專門的分支來開發(fā)。這樣可以在把新功能集成到正式項目前，用Pull Requests的方式討論變更。
功能分支工作流背后的核心思路是所有的功能開發(fā)應(yīng)該在一個專門的分支，而不是在master分支上。 這個隔離可以方便多個開發(fā)者在各自的功能上開發(fā)而不會弄亂主干代碼。 另外，也保證了master分支的代碼一定不會是有問題的，極大有利于集成環(huán)境。
功能開發(fā)隔離也讓pull requests工作流成功可能， pull requests工作流能為每個分支發(fā)起一個討論，在分支合入正式項目之前，給其它開發(fā)者有表示贊同的機會。 另外，如果你在功能開發(fā)中有問題卡住了，可以開一個pull requests來向同學(xué)們征求建議。 這些做法的重點就是，pull requests讓團隊成員之間互相評論工作變成非常方便！
功能分支除了可以隔離功能的開發(fā)，也使得通過Pull Requests討論變更成為可能。 一旦某個開發(fā)者完成一個功能，不是立即合并到master，而是push到中央倉庫的功能分支上并發(fā)起一個Pull Request請求，將修改合并到master。 在修改成為主干代碼前，這讓其它的開發(fā)者有機會先去Review變更。
Code Review是Pull Requests的一個重要的收益，而Pull Requests則是討論代碼的一個通用方式。 你可以把Pull Requests作為專門給某個分支的討論。這意味著可以在更早的開發(fā)過程中就可以進(jìn)行Code Review。

功能分支工作流比上面的集中工作流多出的兩點亮點：

相當(dāng)于在master分支以外，增加了一堆特定功能開發(fā)的feature分支，用于代碼隔離

增加了Pull Request流程，為每個分支開一個 Pull Request 用于開發(fā)者之間進(jìn)行討論（開發(fā)此功能的開發(fā)者遇到問題，可以向其他人征求建議；開發(fā)者完成此功能開發(fā)后，需要其他人進(jìn)行 code review 表示同意之后才能夠進(jìn)行合并分支；此外，為了防止 Pull Request 過多，而很少有人進(jìn)行 code review ，則可以制定一個規(guī)定：如果想要提出一個 Pull Request ，則必須先對其他人的 Pull Request 進(jìn)行 code review 之后才行（這是在另一本書上看到的，應(yīng)該是《GitHub入門》or《Git、Github、GitSesver的24門課》其中一本）

Git Flow 工作流

Gitflow工作流通過為 功能開發(fā) 、 發(fā)布準(zhǔn)備 和 維護(hù) 分配獨立的分支，讓發(fā)布迭代過程更流暢。嚴(yán)格的分支模型也為 大型項目提供了一些非常必要的結(jié)構(gòu)。
雖然比功能分支工作流復(fù)雜幾分，但提供了用于一個健壯的用于管理大型項目的框架。
相對于使用僅有的一個master分支，Gitflow工作流使用兩個分支來記錄項目的歷史。master分支存儲了正式發(fā)布的歷史，而develop分支作為功能的集成分支。 這樣也方便master分支上的所有提交分配一個版本號。
每個新功能位于一個自己的分支，這樣可以push到中央倉庫以備份和協(xié)作。 但功能分支不是從master分支上拉出新分支，而是使用develop分支作為父分支。當(dāng)新功能完成時，合并回develop分支。 新功能提交應(yīng)該從不直接與master分支交互。
從各種含義和目的上來看，功能分支加上develop分支就是功能分支工作流的用法。但Gitflow工作流沒有在這里止步。
一旦develop分支上有了做一次發(fā)布（或者說快到了既定的發(fā)布日）的足夠功能，就從develop分支上checkout一個發(fā)布分支。 新建的分支用于開始發(fā)布循環(huán)，所以從這個時間點開始之后新的功能不能再加到這個分支上—— 這個分支只應(yīng)該做Bug修復(fù)、文檔生成和其它面向發(fā)布任務(wù)。 一旦對外發(fā)布的工作都完成了，發(fā)布分支合并到master分支并分配一個版本號打好Tag。 另外，這些從新建發(fā)布分支以來的做的修改要合并回develop分支。
使用一個用于發(fā)布準(zhǔn)備的專門分支，使得一個團隊可以在完善當(dāng)前的發(fā)布版本的同時，另一個團隊可以繼續(xù)開發(fā)下個版本的功能。 這也打造定義良好的開發(fā)階段（比如，可以很輕松地說，『這周我們要做準(zhǔn)備發(fā)布版本4.0』，并且在倉庫的目錄結(jié)構(gòu)中可以實際看到）。
常用的分支約定：

用于新建發(fā)布分支的分支: develop
用于合并的分支: master
分支命名: release-* 或 release/*
維護(hù)分支或說是熱修復(fù)（hotfix）分支用于給產(chǎn)品發(fā)布版本（production releases）快速生成補丁，這是唯一可以直接從master分支fork出來的分支。 修復(fù)完成，修改應(yīng)該馬上合并回master分支和develop分支（當(dāng)前的發(fā)布分支），master分支應(yīng)該用新的版本號打好Tag。
為Bug修復(fù)使用專門分支，讓團隊可以處理掉問題而不用打斷其它工作或是等待下一個發(fā)布循環(huán)。 你可以把維護(hù)分支想成是一個直接在master分支上處理的臨時發(fā)布。

相比于前面集中式工作流（只有1個master分支）和功能分支工作流（1個master和多個feature分支），Git Flow 工作流瞬間增加了3種不同的分支：develop、release、hotfix。當(dāng)增加這三種分支之后，整個的工作流程變得比較復(fù)雜，每種分支的作用也有一點不同。

• master：在前面兩種工作流中，完全作為主分支，發(fā)布、維護(hù)這唯一的分支，其他的分支（其實也就只有feature分支）都把master分支作父分支而直接交互；而在此工作流中，master分支則是作為歷史分支，存儲了正式發(fā)布的歷史，需要為master分支打上版本號Tag。
• develop：它也記錄著項目的歷史，只不過是作為feature分支的集成分支，記錄的是開發(fā)過程的歷史。感覺它其實替代了之前兩種工作流的master分支部分功能，在此工作流中，所有的feature分支都把develop作為父分支而直接交互，所有開發(fā)過程中的feature分支提交合并，也都是在develop上進(jìn)行。當(dāng)然最初的develop分支肯定是從master分支出來的。
• feature：這個分支的作用和在前面兩種工作流中的作用一致，仍然是開發(fā)新功能時候使用，只是它的父分支從master分支變成了develop分支。
• release：發(fā)布分支，當(dāng)develop分支開發(fā)得差不多了，能夠到發(fā)布的時候，就從develop分支上checkout一個發(fā)布分支出來，然后感覺應(yīng)該是重心就圍繞release分支，為發(fā)布做準(zhǔn)備，從這個時間點開始之后新的功能不能再加到這個分支上—— 這個分支只應(yīng)該做Bug修復(fù)、文檔生成和其它面向發(fā)布任務(wù)。，如果按照這里理解的話，應(yīng)該是說直接在release分支上進(jìn)行一些bug修復(fù)和小規(guī)模的修改和完善（達(dá)不到需要建立分支的程度？感覺如果bug比較大可能會需要建立分支吧，甚至如果更大的bug可能會把release分支又和develop分支合并，繼續(xù)在develop上面做開發(fā)才行）。而如果release分支的發(fā)布工作全部準(zhǔn)備好了，則會合并到master分支打上一個tag，同時合并回develop，同時刪除release分支，如果要求code review，這是一個發(fā)起 Pull Request 的理想時機，即準(zhǔn)備正式發(fā)布到master和合并到develop上。 。使得一個團隊可以在完善當(dāng)前的發(fā)布版本的同時，另一個團隊可以繼續(xù)開發(fā)下個版本的功能。這句話有點點不懂，如果一個團隊在release分支上完善當(dāng)前的發(fā)布版本，另一個團隊只能就著之前并不太完善的develop分支進(jìn)行下一個版本功能的開發(fā)，最后如果從release分支合并回develop時，那就是一個完善的上一個版本和添加了許多新功能的不太完善的版本，感覺可能會產(chǎn)生比較多的沖突，合并分支的時候會比較麻煩。除非新功能等代碼塊模塊化做得很好，可能會比較好一些吧。另外release分支的命名一般也會加上版本號or描述性的名稱，畢竟它也只是一個中間版本，并不是最終的發(fā)布版。release分支是清理發(fā)布、執(zhí)行所有測試、更新文檔和其它為下個發(fā)布做準(zhǔn)備操作的地方，像是一個專門用于改善發(fā)布的功能分支。只要創(chuàng)建這個分支并push到中央倉庫，這個發(fā)布就是 **功能凍結(jié)** 的。任何不在develop分支中的新功能都推到下個發(fā)布循環(huán)中。
• hotfix：維護(hù)分支，好像有些地方把這個hotfix也取做bugfix，它是唯一可以直接從master分支中fork出來的分支，它的父分支是master，而它為發(fā)布版本修復(fù)補丁之后，馬上合并到master和develop分支，master每次被合并的時候都要用新的版本號打上Tag，合并到develop分支之后，這個hotfix分支就可以刪掉了。

做個小結(jié)，整體來說，master、develop是貫穿整個項目始終的永遠(yuǎn)不會被刪除的分支，而feature功能分支在功能完成之后就會被合并到develop中，該分支就可以刪掉；而release發(fā)布分支也是當(dāng)發(fā)布準(zhǔn)備完成后，發(fā)布到master，合并到develop后就可以刪掉；而hotfix維護(hù)分支更是在修改維護(hù)完成之后，發(fā)布到master，合并到develop即可刪除。其中release分支和feature分支可以同時進(jìn)行，通過限定軟件版本實現(xiàn)的功能，在版本范圍內(nèi)的，就在release中完善，而在版本范圍外的就在新feature功能分支中進(jìn)行下一個版本的開發(fā)，這里存在一個并行開發(fā)的流程。

Forking 工作流

Forking工作流是分布式工作流，充分利用了Git在分支和克隆上的優(yōu)勢。可以安全可靠地管理大團隊的開發(fā)者（developer），并能接受不信任貢獻(xiàn)者（contributor）的提交。
不是使用單個服務(wù)端倉庫作為『中央』代碼基線，而讓各個開發(fā)者都有一個服務(wù)端倉庫。這意味著各個代碼貢獻(xiàn)者有2個Git倉庫而不是1個：一個本地私有的，另一個服務(wù)端公開的。
主要優(yōu)勢是，貢獻(xiàn)的代碼可以被集成，而不需要所有人都能push代碼到僅有的中央倉庫中。 開發(fā)者push到自己的服務(wù)端倉庫，而只有項目維護(hù)者才能push到正式倉庫。 這樣項目維護(hù)者 可以接受任何開發(fā)者的提交，但無需給他正式代碼庫的寫權(quán)限。能為 大型、自發(fā)性的團隊（包括了不受信的第三方） 提供靈活的方式來安全的協(xié)作。
要提交本地修改時，push提交到自己公開倉庫中 —— 而不是正式倉庫中。 然后，給正式倉庫發(fā)起一個pull request，讓項目維護(hù)者知道有更新已經(jīng)準(zhǔn)備好可以集成了。 對于貢獻(xiàn)的代碼，pull request也可以很方便地作為一個討論的地方。
集成功能到正式代碼庫，維護(hù)者pull貢獻(xiàn)者的變更到自己的本地倉庫中，檢查變更以確保不會讓項目出錯， 合并變更到自己本地的master分支， 然后pushmaster分支到服務(wù)器的正式倉庫中。 到此，貢獻(xiàn)的提交成為了項目的一部分，其它的開發(fā)者應(yīng)該執(zhí)行pull操作與正式倉庫同步自己本地倉庫。
『官方』倉庫的叫法只是一個約定，理解這點很重要。 從技術(shù)上來看，各個開發(fā)者倉庫和正式倉庫在Git看來沒有任何區(qū)別。 事實上，讓正式倉庫之所以正式的唯一原因是它是項目維護(hù)者的公開倉庫。
各個開發(fā)者應(yīng)該用分支隔離各個功能，就像在功能分支工作流和Gitflow工作流一樣。 唯一的區(qū)別是這些分支被共享了。在Forking工作流中這些分支會被pull到另一個開發(fā)者的本地倉庫中，而在功能分支工作流和Gitflow工作流中是直接被push到正式倉庫中。
相比前面介紹的工作流只用了一個origin遠(yuǎn)程別名指向中央倉庫，Forking工作流需要2個遠(yuǎn)程別名 —— 一個指向正式倉庫，另一個指向開發(fā)者自己的服務(wù)端倉庫。別名的名字可以任意命名，常見的約定是使用origin作為遠(yuǎn)程克隆的倉庫的別名 （這個別名會在運行g(shù)it clone自動創(chuàng)建）， upstream（上游）作為正式倉庫的別名。
保持本地倉庫和正式倉庫的同步更新。
由于開發(fā)者應(yīng)該都在專門的功能分支上工作，pull操作結(jié)果會都是快進(jìn)合并。
開發(fā)者要通知項目維護(hù)者，想要合并他的新功能到正式庫中。 Bitbucket和Stash提供了Pull Request按鈕，彈出表單讓你指定哪個分支要合并到正式倉庫。 一般你會想集成你的功能分支到上游遠(yuǎn)程倉庫的master分支中。
這個工作流實際上就是在功能分支工作流之上引入另一個抽象層。 不是直接通過單個中央倉庫來分享分支，而是把貢獻(xiàn)代碼發(fā)布到開發(fā)者自己的服務(wù)端倉庫中。

感覺這種工作流其實就是Github使用的工作流（但和后文調(diào)研發(fā)現(xiàn)看到的Github Flow不同）：如果有人想要對某個開源項目做貢獻(xiàn)，就 Fork-Push-Pull Request，維護(hù)者審核OK，合并變更提交到正式倉庫。感覺這個工作流最大的優(yōu)勢就是最初所說的分布式，而且可以接受不可信任的第三方提交代碼，而不會影響到原本的代碼。其次需要注意的一點是，如果是Fork正式倉庫后，要添加功能，一定要自建feature分支進(jìn)行修改，然后提交Pull Request給維護(hù)者，這樣才能夠進(jìn)行快速合并。
這個工作流和上面3種工作流最大的區(qū)別在于遠(yuǎn)端的同樣的倉庫有多個，每個開發(fā)者都有一個遠(yuǎn)端倉庫，而前面三種工作流其實遠(yuǎn)端都只有一個倉庫。正如文中所說『官方』倉庫的叫法只是一個約定，理解這點很重要。 從技術(shù)上來看，各個開發(fā)者倉庫和正式倉庫在Git看來沒有任何區(qū)別。 事實上，讓正式倉庫之所以正式的唯一原因是它是項目維護(hù)者的公開倉庫。

Pull Requests 工作流

Pull requests是Bitbucket提供的讓開發(fā)者更方便地進(jìn)行協(xié)作的功能，提供了友好的Web界面可以在提議的修改合并到正式項目之前對修改進(jìn)行討論。
開發(fā)者向團隊成員通知功能開發(fā)已經(jīng)完成，Pull Requests是最簡單的用法。 開發(fā)者完成功能開發(fā)后，通過Bitbucket賬號發(fā)起一個Pull Request。 這樣讓涉及這個功能的所有人知道要去做Code Review和合并到master分支。
Pull Request遠(yuǎn)不止一個簡單的通知，而是為討論提交的功能的一個專門論壇。 如果變更有任何問題，團隊成員反饋在Pull Request中，甚至push新的提交微調(diào)功能。 所有的這些活動都直接跟蹤在Pull Request中。
這種分享提交的形式有助于打造一個更流暢的工作流。
當(dāng)要發(fā)起一個Pull Request，你所要做的就是請求（Request）另一個開發(fā)者（比如項目的維護(hù)者） 來pull你倉庫中一個分支到他的倉庫中。這意味著你要提供4個信息以發(fā)起Pull Request： 源倉庫、源分支、目的倉庫、目的分支。
Pull Request可以和功能分支工作流、Gitflow工作流或Forking工作流一起使用。 但一個Pull Request要求 要么分支不同要么倉庫不同，所以不能用于集中式工作流。【因為集中式工作流只有一個master分支一個遠(yuǎn)程倉庫……】
基本的過程是這樣的：

開發(fā)者在本地倉庫中新建一個專門的分支開發(fā)功能。
開發(fā)者push分支修改到公開的Bitbucket倉庫中。
開發(fā)者通過Bitbucket發(fā)起一個Pull Request。
團隊的其它成員review code，討論并修改。
項目維護(hù)者合并功能到官方倉庫中并關(guān)閉Pull Request。
在功能分支工作流中使用Pull Request：功能分支工作流用一個共享的Bitbucket倉庫來管理協(xié)作，開發(fā)者在專門的分支上開發(fā)功能。 但不是立即合并到master分支上，而是在合并到主代碼庫之前開發(fā)者應(yīng)該開一個Pull Request發(fā)起功能的討論。功能分支工作流只有一個公開的倉庫，所以Pull Request的目的倉庫和源倉庫總是同一個。 通常開發(fā)者會指定他的功能分支作為源分支，master分支作為目的分支。收到Pull Request后，項目維護(hù)者要決定如何做。如果功能沒問題，就簡單地合并到master分支，關(guān)閉Pull Request。 但如果提交的變更有問題，他可以在Pull Request中反饋。之后新加的提交也會評論之后接著顯示出來。在功能還沒有完全開發(fā)完的時候，也可能發(fā)起一個Pull Request。 比如開發(fā)者在實現(xiàn)某個需求時碰到了麻煩，他可以發(fā)一個包含正在進(jìn)行中工作的Pull Request。 其它的開發(fā)者可以在Pull Request提供建議，或者甚至直接添加提交來解決問題。
在Gitflow工作流中使用Pull Request：Gitflow工作流和功能分支工作流類似，但圍繞項目發(fā)布定義一個嚴(yán)格的分支模型。 在Gitflow工作流中使用Pull Request讓開發(fā)者在發(fā)布分支或是維護(hù)分支上工作時， 可以有個方便的地方對關(guān)于發(fā)布分支或是維護(hù)分支的問題進(jìn)行交流。
在Forking工作流中使用Pull Request：在Forking工作流中，開發(fā)者push完成的功能到他自己的倉庫中，而不是共享倉庫。 然后，他發(fā)起一個Pull Request，讓項目維護(hù)者知道他的功能已經(jīng)可以Review了。在這個工作流，Pull Request的通知功能非常有用， 因為項目維護(hù)者不可能知道其它開發(fā)者在他們自己的倉庫添加了提交。Pull Request的源倉庫和目標(biāo)倉庫不是同一個。 源倉庫是開發(fā)者的公開倉庫，源分支是包含了修改的分支。 如果開發(fā)者要合并修改到正式代碼庫中，那么目標(biāo)倉庫是正式倉庫，目標(biāo)分支是master分支。Pull Request也可以用于正式項目之外的其它開發(fā)者之間的協(xié)作。 比如，如果一個開發(fā)者和一個團隊成員一起開發(fā)一個功能，他們可以發(fā)起一個Pull Request， 用團隊成員的Bitbucket倉庫作為目標(biāo)，而不是正式項目的倉庫。 然后使用相同的功能分支作為源和目標(biāo)分支。
如果需要小明以外的人審核批準(zhǔn)代碼，可以把這些人填在【Reviewers】文本框中。
Pull Request并不是為了替代任何 基于Git的協(xié)作工作流， 而是它們的一個便利的補充，讓團隊成員間的協(xié)作更輕松方便。

在后文的其他帖子中有看到只介紹了前面四種工作流，最后的Pull Request感覺被集成到了前面的4種工作流當(dāng)中，作為一種討論、解決、跟蹤、及時反饋的工具。

企業(yè)日常開發(fā)模式

在企業(yè)開發(fā)中，使用 Git 作為版本控制軟件最看重的還是結(jié)合公司自己搭建的 Gitlab，將 Code Review 加入打包部署持續(xù)集成的流程中，這樣，代碼開發(fā)完成，提交測試前，便可以對開發(fā)人員提交的代碼進(jìn)行 Review，發(fā)現(xiàn)潛在的問題，及時指導(dǎo)，對于新人來講，也能更快更好的學(xué)習(xí)。

master：master永遠(yuǎn)是線上代碼，最穩(wěn)定的分支，存放的是隨時可供在生產(chǎn)環(huán)境中部署的代碼，當(dāng)開發(fā)活動告一段落，產(chǎn)生了一份新的可供部署的代碼時，發(fā)布成功之后，代碼才會由 aone2 提交到 master，master 分支上的代碼會被更新。應(yīng)用上 aone2 后禁掉所有人的 master的寫權(quán)限
develop：保存當(dāng)前最新開發(fā)成果的分支。通常這個分支上的代碼也是可進(jìn)行每日夜間發(fā)布的代碼，只對開發(fā)負(fù)責(zé)人開放develop權(quán)限。
feature: 功能特性分支，每個功能特性一個 feature/ 分支，開發(fā)完成自測通過后合并入 develop 分支。可以從 master 或者develop 中拉出來。
hotfix: 緊急bug分支修復(fù)分支。修復(fù)上線后，可以直接合并入master。
develop 作為固定的持續(xù)集成和發(fā)布分支，并且分支上的代碼必須經(jīng)過 CodeReview 后才可以提交到 Develop 分支。它的基本流程如下：
每一個需求/變更都單獨從Master上創(chuàng)建一條Branch分支；
用戶在這個Branch分支上進(jìn)行Codeing活動；
代碼達(dá)到發(fā)布準(zhǔn)入條件后aone上提交Codereview，Codereview通過后代碼自動合并到Develop分支；
待所有計劃發(fā)布的變更分支代碼都合并到Develop后，系統(tǒng)再 rebase master 代碼到Develop 分支，然后自行構(gòu)建，打包，部署等動作。
應(yīng)用發(fā)布成功后Aone會基于Develop分支的發(fā)布版本打一個“當(dāng)前線上版本Tag”基線；
應(yīng)用發(fā)布成功后Aone會自動把Develop分支的發(fā)布版本合并回master；

整體感覺如果是企業(yè)開發(fā)大型項目的話，還是主要參照Git Flow的多分支進(jìn)行的一些微調(diào)，雖然這種工作流比較復(fù)雜，但是對于大型項目的管理來說比較有用，而且也適合快速迭代開發(fā)。

后面有對開發(fā)工作流的一些討論，支持看一下原文，而且里面有一些圖，講解的更為詳細(xì)，很不錯。

Git三大特色之WorkFlow(工作流)

這篇介紹了使用較高的3種工作流：Git Flow、Github Flow、Gitlab Flow。里面有一些需要注意的地方：

Git Flow 的作者 Vincent Driessen 非常建議，合并分支的時候，加上 no-ff 參數(shù)，這個參數(shù)的意思是不要選擇 Fast-Forward 合并方式，而是策略合并，策略合并會讓我們多一個合并提交。這樣做的好處是保證一個非常清晰的提交歷史，可以看到被合并分支的存在。
master 分支每合并一個分支，無論是 hotfix 還是 release ,都會打一個版本標(biāo)簽。通過箭頭可以清楚的看到分支的開始和結(jié)束走向，例如 feature 分支從 develop 開始，最終合并回 develop ，hoxfixes 從 master 檢出創(chuàng)建，最后合并回 develop 和 master，master 也打上了標(biāo)簽。

里面對Github Flow工作流中的Pull Request和issue tracking有一些介紹，這部分還不是特別有經(jīng)驗，后面慢慢嘗試使用。
這里對Git Flow & GitHub Flow 的瑕疵進(jìn)行了分析，然后對GitLab Flow進(jìn)行了介紹，它基于前兩者的缺點進(jìn)行了一些優(yōu)化，感覺這算是比較新的工作流（因為沒有在最上面的那個全的里面被列出來）。主要解決了3個問題：

版本的延遲發(fā)布–Prodution Branch：master 分支不夠，于是添加了一個 prodution 分支，專門用來發(fā)布版本。
不同環(huán)境的部署–Environment Branches & Upstream First：每個環(huán)境，都對應(yīng)一個分支，例如下圖中的 pre-production 和 prodution 分支都對應(yīng)不同的環(huán)境，我覺得這個工作流模型比較適用服務(wù)端，測試環(huán)境，預(yù)發(fā)環(huán)境，正式環(huán)境，一個環(huán)境建一個分支。比較適用服務(wù)端，測試環(huán)境，預(yù)發(fā)環(huán)境，正式環(huán)境，一個環(huán)境建一個分支。要注意，代碼合并的順序，要按環(huán)境依次推送，確保代碼被充分測試過,才會從上游分支合并到下游分支。除非是很緊急的情況，才允許跳過上游分支，直接合并到下游分支。這個被定義為一個規(guī)則，名字叫 “upstream first”，翻譯過來是 “上游優(yōu)先”。
版本發(fā)布分支–Release Branches & Upstream First：只有當(dāng)對外發(fā)布軟件的時候，才需要創(chuàng)建 release 分支。在 Git Flow ,版本記錄是通過 master 上的 tag 來記錄。發(fā)現(xiàn)問題，創(chuàng)建 hotfix 分支，完成之后合并到 master 和 develop。在 GitLab Flow ，建議的做法是每一個穩(wěn)定版本，都要從master分支拉出一個分支，比如2-3-stable、2-4-stable等等。發(fā)現(xiàn)問題，就從對應(yīng)版本分支創(chuàng)建修復(fù)分支，完成之后，先合并到 master，才能再合并到 release 分支，遵循 “上游優(yōu)先” 原則。

感覺Gitlab Flow說是解決了前面的兩種工作流的缺點，它的兩種適用場景分別是"持續(xù)發(fā)布"和"版本發(fā)布"的項目；然后搜了下，發(fā)現(xiàn)這里是阮一峰大神寫的工作流介紹。里面說：

Git Flow

Git flow的優(yōu)點是清晰可控，缺點是相對復(fù)雜，它是基于"版本發(fā)布"的，目標(biāo)是一段時間以后產(chǎn)出一個新版本。但是，很多網(wǎng)站項目是"持續(xù)發(fā)布"，代碼一有變動，就部署一次。這時，master分支和develop分支的差別不大，沒必要維護(hù)兩個長期分支。

Github Flow

Github flow 是Git flow的簡化版，專門配合"持續(xù)發(fā)布"。它是 Github.com 使用的工作流程。Github flow 的最大優(yōu)點就是簡單，對于"持續(xù)發(fā)布"的產(chǎn)品，可以說是最合適的流程。問題在于它的假設(shè)：master分支的更新與產(chǎn)品的發(fā)布是一致的。也就是說，master分支的最新代碼，默認(rèn)就是當(dāng)前的線上代碼。可是，有些時候并非如此，代碼合并進(jìn)入master分支，并不代表它就能立刻發(fā)布。比如，蘋果商店的APP提交審核以后，等一段時間才能上架。這時，如果還有新的代碼提交，master分支就會與剛發(fā)布的版本不一致。另一個例子是，有些公司有發(fā)布窗口，只有指定時間才能發(fā)布，這也會導(dǎo)致線上版本落后于master分支。上面這種情況，只有master一個主分支就不夠用了。通常，你不得不在master分支以外，另外新建一個production分支跟蹤線上版本。

Gitlab Flow

Gitlab flow 的最大原則叫做"上游優(yōu)先"（upsteam first），即只存在一個主分支master，它是所有其他分支的"上游"。只有上游分支采納的代碼變化，才能應(yīng)用到其他分支。對于"持續(xù)發(fā)布"的項目，它建議在master分支以外，再建立不同的環(huán)境分支。比如，"開發(fā)環(huán)境"的分支是master，"預(yù)發(fā)環(huán)境"的分支是pre-production，"生產(chǎn)環(huán)境"的分支是production。開發(fā)分支是預(yù)發(fā)分支的"上游"，預(yù)發(fā)分支又是生產(chǎn)分支的"上游"。代碼的變化，必須由"上游"向"下游"發(fā)展。比如，生產(chǎn)環(huán)境出現(xiàn)了bug，這時就要新建一個功能分支，先把它合并到master，確認(rèn)沒有問題，再cherry-pick到pre-production，這一步也沒有問題，才進(jìn)入production。只有緊急情況，才允許跳過上游，直接合并到下游分支。對于"版本發(fā)布"的項目，建議的做法是每一個穩(wěn)定版本，都要從master分支拉出一個分支，比如2-3-stable、2-4-stable等等。以后，只有修補bug，才允許將代碼合并到這些分支，并且此時要更新小版本號。

Gitlab Flow官網(wǎng)鏈接

其他資料

Git資源集合：這個是從上面這篇的連接看到的，整合了很多的Git相關(guān)的學(xué)習(xí)資料or資源，可以作為后續(xù)的學(xué)習(xí)方向，很6。
GitFlow工作流常用操作流程：這篇是一個公司編寫的，詳細(xì)講了他們公司是怎么使用Git Flow工作流的。這里把 hotfix 直接取名為 bugfix 了，作用還一致的，就是在發(fā)布的master分支上進(jìn)行bug修復(fù)。感覺和上面描述的主要不同在于release分支，上面是說用于做發(fā)布前的準(zhǔn)備，如文檔添加等一些小問題的，這里就直接把release分支作為測試分支了，develop分支開發(fā)完成后，直接就在這里做測試，如果發(fā)現(xiàn)小bug，就在release分支中進(jìn)行修復(fù)。感覺如果是就是做測試分支了，干嘛不直接叫Test分支好了。不過還是有一些借鑒意義，寫得也比較全面，可以參考。
Git 工作流的一些經(jīng)驗分享：這篇其實是最先看到的一篇，對前面4種工作流簡單評價了一下，適合簡單概念性的入門，能夠?qū)γ糠N工作流有個大概的認(rèn)識，然后再去深入看上面的這篇會更容易理解。他后面的Git Flow工作流的實踐簡單看了下，最大的特別是hotfix分支不是從master拉的，而是從develop分支拉取的。release分支用于回歸測試和bug修復(fù)，其他的分支功能和Git Flow上面講解的差不多。
Git Flow工作流程：也是只對Git Flow工作流進(jìn)行了介紹，不過里面寫了分支的命名規(guī)范，感覺不錯，可以參考：

主分支名稱：master
主開發(fā)分支名稱：develop
標(biāo)簽（tag）名稱：v.RELEASE，其中”“ 為版本號，“RELEASE”大寫，如：v1.0.0.RELEASE
新功能開發(fā)分支名稱：feature-or feature/，其中“” 為新功能簡述，如：feature-item-activity-list
發(fā)布分支名稱：release-or release/，其中為版本號，“release”小寫，如：release-1.0.0
master的bug修復(fù)分支名稱：hotfix-or hotfix/，其中*為bug簡述，如：hotfix/item-update-bug

總結(jié)

看了這么多種Git的工作流，感覺比較核心一些共同的思想點如下：

master分支上的版本是最新、最官方、沒有問題的版本，要保護(hù)好master上的代碼，不能輕易的提交、合并分支

每次新開發(fā)一個功能、修復(fù)bug……等任何事情，都不能直接在master分支上進(jìn)行操作，而是需要重新開一個分支，在這個分支上進(jìn)行操作

想要請求合并分支的時候，不管是什么合并，特別是涉及到master的分支合并時，一定要開 Pull Request 進(jìn)行 code review，審核之后才能合并

當(dāng)然如果在開發(fā)過程中也可以善用PR進(jìn)行討論和問題跟蹤

最后回歸本源：

在閱讀的過程中請記住，本文中的幾種工作流是作為方案指導(dǎo)而不是條例規(guī)定。在展示了各種工作流可能的用法后，你可以從不同的工作流中挑選或揉合出一個滿足你自己需求的工作流。

任何工作流程都只是規(guī)范or標(biāo)準(zhǔn)or推薦，但是并不一定適用于所有的項目、所有的場景、所有的開發(fā)人員，針對不同的情況，需要靈活調(diào)整。

轉(zhuǎn)載于:https://www.cnblogs.com/Chayeen/p/9989628.html

總結(jié)

以上是生活随笔為你收集整理的Git多人协作工作流程的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。