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