一、Git介紹
Git是一個項目源碼管理系統，在多人合作開發過程中是至關重要的。在項目開發中，我們可以通過Git客戶端(Github、Tower、Tortoise等)或者通過命令行來使用Git，關於Git基礎操作的命令參考文章Git基本操作命令。即使是在獨立開發過程中，使用Git管理項目也是有很多的好處的，便於記錄版本歷史、隨時進行版本回退等等。協作則必須有一個規範的工作流程，讓大家有效的合作，使得項目井井有條的發展下去。下面就介紹下Git中常用的三種Git工作流程。
二、三種常用的Git工作流程(Git Flow、Github Flow、GitLab Flow)介紹
1.Git Flow：
Git Flow是最早的一種Git工作流程，他有兩個特點:(1).項目存在兩個長期分支; (2).項目存在三中短期分支
長期分支：develop分支、master分支。develop分支用於開發，存放最新的開發版；master分支用於存放最新的穩定版本。
短期分支：功能分支(feature branch)、補丁分支(hotfix branch)、預發分支(release branch)。這三種短期分支在完成開發後會被合併 到develop分支或者master分中，然後被刪除掉。
評價：
Git flow的優點是清晰可控，缺點是相對複雜，需要同時維護兩個長期分支。大多數工具都將master當作默認分支，可是開發
是在develop分支進行的，這導致經常要切換分支，非常煩人。
更大問題在於，這個模式是基於"版本發佈"的，目標是一段時間以後產出一個新版本。但是，很多網站項目是"持續發佈"，
代碼一有變動，就部署一次。這時，master分支和develop分支的差別不大，沒必要維護兩個長期分支。
模型圖：
2.Github Flow:
Github flow 是Git flow的簡化版，專門配合"持續發佈"。它是 Github.com 使用的工作流程。
操作流程： 第一步：根據需求，從master拉出新分支，不區分功能分支或補丁分支。
第二步：新分支開發完成後，或者需要討論的時候，就向master發起一個pull request（簡稱PR）。
第三步：Pull Request既是一個通知，讓別人注意到你的請求，又是一種對話機制，大家一起評審和討論你的代碼。
對話過程中，你還可以不斷提交代碼。
第四步：你的Pull Request被接受，合併進master，重新部署後，原來你拉出來的那個分支就被刪除。（先部署再合
並也可。）
評價： Github flow 的最大優點就是簡單，對於"持續發佈"的產品，可以說是最合適的流程。
問題在於它的假設：master分支的更新與產品的發佈是一致的。也就是說，master分支的最新代碼，默認就是當前的線上
代碼。
可是，有些時候並非如此，代碼合併進入master分支，並不代表它就能立刻發佈。比如，蘋果商店的APP提交審覈以後，
等一段時間才能上架。這時，如果還有新的代碼提交，master分支就會與剛發佈的版本不一致。另一個例子是，有些公司有
發佈窗口，只有指定時間才能發佈，這也會導致線上版本落後於master分支。
上面這種情況，只有master一個主分支就不夠用了。通常，你不得不在master分支以外，另外新建一個production分支跟
蹤線上版本。
模型圖：
3.GitLab Flow
Gitlab flow 是 Git flow 與 Github flow 的綜合。它吸取了兩者的優點，既有適應不同開發環境的彈性，又有單一主分支的簡單和便利。
它是 Gitlab.com 推薦的做法。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，才允許將代碼合併到這些分支，並且此時要更新小版本號。
三、關於Merge request(pull request)
在團隊開發中，我們作爲項目代碼管理者，我們要給小弟設置權限，設置保護分支。一般常用有兩種管理方式。
1.團隊中所有人都在master分支中開發，給其他人設置developer角色權限，設置保護分支，master所有人都可以push，但是隻能master才能merge。然後需要建立一個穩定分支stable用於記錄線上版本，因爲在開發中可能master分支超前線上版本，這個時候就需啊喲一個分支來記錄線上穩定版本.
2.團隊中其他人都將項目git庫fork到自己名下，然後clone到本地，添加上我們管理員名下git庫的遠程地址，這個時候他們作爲developer的代碼庫就有了兩個遠程地址。我們設置下角色權限，他們只能夠pull我們管理員的代碼，但是不能進行push操作。那我們管理員怎麼去同步其他developer的代碼呢? 他們在完成一個分支feature branch的開發後，將feature branch push到他們自己的遠程git庫，然後發起merge request，申請將這個feature branch 合併到我們管理員的master分支，這個時候我們需要check out這個feature branch進行代碼review，如果沒問題則同意這次merge request，並刪除這個合併請求分支。這樣設置，其他developer可以更新我們管理員的代碼，但是他們的修改不會直接影響到我們的代碼，這樣就能避免其他developer的錯誤操作導致項目出現不必要的Bug或者conflict。