團隊開發(fā)中，遵循一個合理、清晰的Git使用流程，是非常重要的。否則，每個人都提交一堆雜亂無章的commit，項目很快就會變得難以協(xié)調(diào)和維護。

Git 的一般工作流程如下：

一、克隆 Git 資源作為工作目錄；

二、在克隆的資源上添加或修改文件；

三、如果其他人修改了，你可以更新資源；

四、在提交前查看修改；

五、提交修改；

六、在修改完成后，如果發(fā)現(xiàn)錯誤，可以撤回提交并再次修改并提交。

分布式工作流程

與傳統(tǒng)的集中式版本控制系統(tǒng)相反，Git 的分布式特性使得開發(fā)者間的協(xié)作變得更加靈活多樣。在集中式系統(tǒng)中，每個開發(fā)者就像是連接在集線器上的節(jié)點，彼此的工作方式大體相像。而在 Git 中，每個開發(fā)者同時扮演著節(jié)點和集線器的角色——也就是說， 每個開發(fā)者既可以將自己的代碼貢獻到其他的倉庫中，同時也能維護自己的公開倉庫， 讓其他人可以在其基礎(chǔ)上工作并貢獻代碼。由此，Git 的分布式協(xié)作可以為你的項目和團隊衍生出種種不同的工作流程， 接下來介紹幾種利用了 Git 的這種靈活性的常見應(yīng)用方式。我們將討論每種方式的優(yōu)點以及可能的缺點；我們可以選擇使用其中的某一種，或者將它們的特性混合搭配使用。

集中式工作流程

集中式系統(tǒng)中通常使用的是單點協(xié)作模型——集中式工作流。一個中心集線器，或者說倉庫，可以接受代碼，所有人將自己的工作與之同步。若干個開發(fā)者則作為節(jié)點，即中心倉庫的消費者與中心倉庫同步。

如果在公司或者團隊中，你已經(jīng)習(xí)慣了使用這種集中式工作流程，完全可以繼續(xù)采用這種簡單的模式。只需要搭建好一個中心倉庫，并給開發(fā)團隊中的每個人推送數(shù)據(jù)的權(quán)限，就可以開展工作了。Git 不會讓用戶覆蓋彼此的修改。

例如 Lucy 和 Lily 同時開始工作。Lucy 完成了他的修改并推送到服務(wù)器。接著 Lily 嘗試提交她自己的修改，卻遭到服務(wù)器拒絕。她被告知她的修改正通過非快進式（non-fast-forward）的方式推送，只有將數(shù)據(jù)抓取下來并且合并后方能推送。這種模式的工作流程的使用非常廣泛，因為大多數(shù)人對其很熟悉也很習(xí)慣。

當(dāng)然這并不局限于小團隊。利用 Git 的分支模型，通過同時在多個分支上工作的方式，即使是上百人的開發(fā)團隊也可以很好地在單個項目上協(xié)作。

主管與副主管工作流程

這其實是多倉庫工作流程的變種。一般擁有數(shù)百位協(xié)作開發(fā)者的超大型項目才會用到這樣的工作方式，例如著名的 Linux 內(nèi)核項目。被稱為副主管（lieutenant） 的各個集成管理者分別負責(zé)集成項目中的特定部分。所有這些副主管頭上還有一位稱為主管（dictator） 的總集成管理者負責(zé)統(tǒng)籌。主管維護的倉庫作為參考倉庫，為所有協(xié)作者提供他們需要拉取的項目代碼。

普通開發(fā)者在自己的主題分支上工作，并根據(jù) master 分支進行變更。這里是主管推送的參考倉庫的 master 分支。

工作流程總結(jié)

上面介紹了在 Git 等分布式系統(tǒng)中經(jīng)常使用的工作流程，但是在實際的開發(fā)中，你會遇到許多可能適合你的特定工作流程的變種?，F(xiàn)在你也許已經(jīng)清楚哪種工作流程組合可能比較適合你了。