長話短說，倉庫內(nèi)部采用 Git flow 模式夜惭，倉庫之間采用 GitHub flow模式姻灶。
開始之前需要先了解下什么是Git flow什么又是GitHub flow。
這兩個(gè)不是誰替代誰的關(guān)系诈茧，而是他們適用的場景不一樣产喉，Git flow專注的是軟件發(fā)布模型，作為一個(gè)商業(yè)軟件敢会，只有一個(gè)master分支是遠(yuǎn)遠(yuǎn)不夠的曾沈，因?yàn)槟愕挠脩舨惶赡芏疾捎猛瑯拥陌姹荆⑶以谟行掳姹竞蠼y(tǒng)一更新鸥昏，即使是互聯(lián)網(wǎng)只有服務(wù)器端的項(xiàng)目也會面臨組織內(nèi)部不同服務(wù)之間的版本依賴問題塞俱。因此，遵循Git flow的建議吏垮，輔以Git flow extensions在倉庫內(nèi)部維護(hù)完整的分支和Tag障涯，如同它文檔標(biāo)題一樣，這樣的分支模型會讓你達(dá)到成功的彼岸膳汪。
而GitHub flow模型關(guān)注的則是協(xié)作唯蝶，拋開個(gè)人solo的項(xiàng)目，每個(gè)項(xiàng)目都會面臨協(xié)作的問題遗嗽。此時(shí)粘我，一個(gè)直觀的想法是給其他人開放Developer權(quán)限，這里告訴你千萬不要這樣干媳谁，尤其是在這個(gè)人沒有經(jīng)過專業(yè)訓(xùn)練的前提下涂滴。正確的姿勢應(yīng)該是友酱，Fork -> Pull Request -> Merge。 Git是一個(gè)分布式的倉庫柔纵，應(yīng)該按照分布式的思維方式來工作缔杉，合作應(yīng)該是倉庫和倉庫之間的事情。這種分布式的思維應(yīng)該運(yùn)用在每個(gè)Git倉庫中搁料，GitHub上的倉庫和你本地的倉庫或详，即使都是你的，并且都是你一個(gè)人在維護(hù)郭计，那么也需要把它理解為這是兩個(gè)倉庫霸琴，在維護(hù)過程中你要扮演兩個(gè)角色，一個(gè)是Developer昭伸，將代碼clone到本地之后梧乘，采用Git flow的模式進(jìn)行工作。然后再扮演另一個(gè)Master的角色庐杨，來維護(hù)Github那個(gè)选调。
So, 在真實(shí)的工作中我們應(yīng)該將這兩者結(jié)合起來。
