集中式工作流
使用
Git加強開發(fā)的工作流却妨，比SVN有幾個優(yōu)勢:
- 每個開發(fā)可以有屬于自己的整個工程的本地拷貝华临。隔離的環(huán)境讓各個開發(fā)者的工作和項目的其他部分（修改）獨立開來 —— 即自由地提交到自己的本地倉庫铃拇，先完全忽略上游的開發(fā)铆隘，直到方便的時候再把修改反饋上去又沾。
- Git提供了強壯的分支和合并模型。不像
SVN归露，Git的分支設計成可以做為一種用來在倉庫之間集成代碼和分享修改的『失敗安全』的機制洲脂。
- 集中式工作流以中央倉庫（master）作為項目所有修改的單點實體。
- 如果開發(fā)者本地的提交歷史和中央倉庫有分歧剧包，Git會拒絕
push提交否則會覆蓋已經(jīng)在中央庫的正式提交恐锦。 - 在開發(fā)者提交自己功能修改到中央庫前，需要先
fetch在中央庫的新增提交疆液，rebase自己提交到中央庫提交歷史之上一铅。
功能分支工作流
功能分支工作流背后的核心思路是所有的功能開發(fā)應該在一個專門的分支，而不是在
master分支上堕油。這個隔離可以方便多個開發(fā)者在各自的功能上開發(fā)而不會弄亂主干代碼潘飘。另外，也保證了master分支的代碼一定不會是有問題的馍迄，極大有利于集成環(huán)境福也。
- 功能分支工作流仍然用中央倉庫局骤，并且
master分支還是代表了正式項目的歷史攀圈。\
- 功能分支可以進行隔離開發(fā)，確保不會干擾主干代碼峦甩，極大有利于集成環(huán)境赘来。
- 功能分支可以實現(xiàn)pull request，使在修改主干代碼前能夠?qū)崿F(xiàn)code review凯傲。
- pull request還可以事實現(xiàn)分支討論與交流犬辰。
Gitflow工作流
Gitflow工作流定義了一個圍繞項目發(fā)布的嚴格分支模型。雖然比功能分支工作流復雜幾分冰单，但提供了用于一個健壯的用于管理大型項目的框架幌缝。
工作方式
Gitflow工作流仍然用中央倉庫作為所有開發(fā)者的交互中心。和其它的工作流一樣诫欠，開發(fā)者在本地工作并push
分支到要中央倉庫中涵卵。
歷史分支
相對使用僅有的一個master分支浴栽，Gitflow工作流使用2個分支來記錄項目的歷史。master分支存儲了正式發(fā)布的歷史轿偎，而develop分支作為功能的集成分支典鸡。這樣也方便master分支上的所有提交分配一個版本號。
功能分支
每個新功能位于一個自己的分支坏晦，這樣可以push到中央倉庫以備份和協(xié)作萝玷。但功能分支不是從master分支上拉出新分支，而是使用develop分支作為父分支昆婿。當新功能完成時球碉，合并回develop分支。新功能提交應該從不直接與master分支交互挖诸。
發(fā)布分支
一旦develop分支上有了做一次發(fā)布（或者說快到了既定的發(fā)布日）的足夠功能汁尺，就從develop分支上fork一個發(fā)布分支。新建的分支用于開始發(fā)布循環(huán)多律，所以從這個時間點開始之后新的功能不能再加到這個分支上 —— 這個分支只應該做Bug修復痴突、文檔生成和其它面向發(fā)布任務。一旦對外發(fā)布的工作都完成了狼荞，發(fā)布分支合并到master分支并分配一個版本號打好Tag辽装。另外，這些從新建發(fā)布分支以來的做的修改要合并回develop分支相味。
使用一個用于發(fā)布準備的專門分支拾积，使得一個團隊可以在完善當前的發(fā)布版本的同時，另一個團隊可以繼續(xù)開發(fā)下個版本的功能丰涉。
這也打造定義良好的開發(fā)階段（比如拓巧，可以很輕松地說，『這周我們要做準備發(fā)布版本4.0』一死，并且在倉庫的目錄結(jié)構中可以實際看到）肛度。
常用的分支約定：
用于新建發(fā)布分支的分支: develop
用于合并的分支: master
分支命名: release-* 或 release/*
維護分支
維護分支或說是熱修復（hotfix）分支用于生成快速給產(chǎn)品發(fā)布版本（production releases）打補丁，這是唯一可以直接從master分支fork出來的分支投慈。修復完成承耿，修改應該馬上合并回master分支和develop分支（當前的發(fā)布分支），master分支應該用新的版本號打好Tag伪煤。
為Bug修復使用專門分支加袋，讓團隊可以處理掉問題而不用打斷其它工作或是等待下一個發(fā)布循環(huán)。你可以把維護分支想成是一個直接在master分支上處理的臨時發(fā)布抱既。
