這篇文章將從開發者和管理者兩方面介紹如何使用git進行團隊合作開發。
1.git 和svn的差異
git和svn 最大的差異在於git是分布式的管理方式而svn是集中式的管理方式。如果不習慣用代碼管理工具，可能比較難理解分布式管理和集中式管理的概念。下面介紹兩種工具的工作流程（團隊開發），通過閱讀下面的工作流程，你將會很好的理解以上兩個概念。
集中式管理的工作流程如下圖（圖2.1）：
集中式代碼管理的核心是服務器，所有開發者在開始新一天的工作之前必須從服務器獲取代碼，然后開發，最后解決沖突，提交。所有的版本信息都放在服務器上。如果脫離了服務器，開發者基本上是不可以工作。下面舉例說明：
開始新一天的工作：
1：從服務器下載項目組最新代碼。
2：進入自己的分支，進行工作，每隔1個小時向服務器自己的分支提交一次代碼（很多人都有這個習慣。因為有時候自己對代碼改來改去，最后又想還原到前一個小時的版本，或者看看前一個小時自己修改了哪些代碼，就需要這樣做了）。
3：下班時間快到了，把自己的分支合並到服務器主分支上，一天的工作完成，並反映給服務器。
這就是經典的svn工作流程，從流程上看，有不少缺點，但也有優點。
缺點：
1、服務器壓力太大，數據庫容量暴增。
2、如果不能連接到服務器上，基本上不可以工作，看上面第二步，如果服務器不能連接上，就不能提交，還原，對比等等。
3、不適合開源開發（開發人數非常非常多，但是Google app engine就是用svn的）。但是一般集中式管理的有非常明確的權限管理機制（例如分支訪問限制），可以實現分層管理，從而很好的解決開發人數眾多的問題。
優點：
1、管理方便，邏輯明確，符合一般人思維習慣。
2、易於管理，集中式服務器更能保證安全性。
3、代碼一致性非常高。
4、適合開發人數不多的項目開發。
5、大部分軟件配置管理的大學教材都是使用svn 和vss。
下面是分布式管理的工作流程，如下圖（圖2.2）：
分布式和集中式的最大區別在於開發者可以在本地提交。每個開發者機器上都有一個服務器的數據庫。
圖2.2就是經典的git開發過程。步驟如下：
一般開發者的角度：
1：從服務器上克隆數據庫（包括代碼和版本信息）到單機上。
2：在自己的機器上創建分支，修改代碼。
3：在單機上自己創建的分支上提交代碼。
4：在單機上合並分支。
5：新建一個分支，把服務器上最新版的代碼fetch下來，然后跟自己的主分支合並。
6：生成補丁（patch），把補丁發送給主開發者。
7：看主開發者的反饋，如果主開發者發現兩個一般開發者之間有沖突（他們之間可以合作解決的沖突），就會要求他們先解決沖突，然后再由其中一個人提交。如果主開發者可以自己解決，或者沒有沖突，就通過。
8：一般開發者之間解決沖突的方法，開發者之間可以使用pull命令解決沖突，解決完沖突之后再向主開發者提交補丁。
主開發者的角度（假設主開發者不用開發代碼）：
1：查看郵件或者通過其它方式查看一般開發者的提交狀態。
2：打上補丁，解決沖突（可以自己解決，也可以要求開發者之間解決以后再重新提交，如果是開源項目，還要決定哪些補丁可用，哪些不用）。
3：向公共服務器提交結果，然后通知所有開發人員。
優點：
適合分布式開發，強調個體。
公共服務器壓力和數據量都不會太大。
速度快、靈活。
任意兩個開發者之間可以很容易的解決沖突。
缺點：
資料少（起碼中文資料很少）。
學習周期相對而言比較長。
不符合常規思維。
代碼保密性差，一旦開發者把整個庫克隆下來就可以完全公開所有代碼和版本信息。
2.git常用命令介紹
git init
創建一個數據庫
git clone
復制一個數據到制定文件夾
git add 和git commit
把想提交的文件add上，然后commit這些文件到本地數據庫。
git pull
從服務器下載數據庫，並跟自己的數據庫合並。
git fetch
從服務器下載數據庫，並放到新分支，不跟自己的數據庫合並。
git whatchanged
查看兩個分支的變化
git branch
創建分支，查看分支，刪除分支
git checkout
切換分支
git merge
合並分支，把目標分支合並到當前分支
git config
配置相關信息，例如email和name
git log
查看版本歷史
git show
查看版本號對於版本的歷史，如果參數是HEAD查看最新版本。
git tag
標定版本號
git reset
恢復到之前的版本
--mixed是git-reset的默認選項，它的作用是重置索引內容，將其定位到指定的項目版本，而不改變你的工作樹中的所有內容，只是提示你有哪些文件還未更新。
--soft選項既不觸動索引的位置，也不改變工作樹中的任何內容。該選項會保留你在工作樹中的所有更新並使之處於待提交狀態。相當於在--mixed基礎上加上git add。
--hard 把整個目錄還原到一個版本，包括所有文件。
git push
向其他數據庫推送自己的數據庫
git status
顯示當前的狀態
git mv
重命名文件或者文件夾
git rm
刪除文件或者文件夾
git help
查看幫助，還有幾個無關緊要的命令，請自己查看幫助。
3.git開發模式
1：大項目開發模式（如圖4.1）
對於項目負責人
1：初始化
對於最終項目負責人：
使用git init --bare在公共服務器上建立一個空數據庫，在自己的機器上通過
或者數據庫（這里需要設置一下訪問權限，由於git沒有提供權限管理功能，所以要通過ssh設置，具體是對下一級子項目項目可讀不可寫，對自己可讀可寫）。
新建一些必要的文件夾和文件放到自己的數據庫上
然后使用
提交到公共服務器上，作為原始版本。
告訴下級公共服務器的地址。
對於子項目負責人：
在子公共服務器上克隆一個數據庫
設置訪問權限，對下級可讀不可寫，對自己可讀可寫。
在自己的計算機中克隆一個數據庫
告訴下級子公共服務器地址。
對於最底層的開發人員：
在上級公共服務器中克隆一個數據庫
2：開展工作
對於最終項目負責人
收來自下級的郵件
在自己的數據庫上建分支，並轉到分支上
重復上述步驟，直到所有補丁打完。
如果發現在合並分支的時候發現有些沖突需要下級項目負責人協助解決的話，可以通知下級項目負責人。
對於子項目負責人：
如果上級項目負責人需要他們之間合作解決某些沖突，他們可以通過
解決沖突。
如果上級項目負責人沒有要求合作解決沖突，那項目負責人應該做以下事情：
然后項目負責人就開始接收郵件，然后打補丁
重復上述工作，直到補丁全部打完。
下面是向上級提交更新的過程
對於最底層的開發人員：
如果上級要求解決沖突，同樣是要解決沖突，然后再提交補丁
如果不用，就從上級服務器更新
然后建分支，並開發代碼
然后是向上級提交代碼
以上就是git在大項目開發中的應用。
但是明顯是不適合我們實驗室的。
原因有三：
1、我們學生中沒有專門的維護人員。
2、我們學生中沒有對全局都很了解架構師。
3、我們的老師可以擔當此重任也只有我們的老師有這樣的實力，但是老師太忙，沒時間每天做這些瑣事。
所以我們需要一種新的合作模式（一種沒有項目負責人的模式）。
這種模式對開發人員的素質要求很高。
合作模式如下圖（圖4.2）：（適合我們實驗室使用）
這種模式的開發流程如下：
1、由其中一個開發者這服務器上建立一個數據庫。
所有開發者都可以向數據庫提交和下載東西，這里必須規定一定的時間間隔（一周或者一天）必須提交一次，不然以后解決沖突時是個大問題。
如果每個人的開發耦合度很高，我們可在服務器上建立分支，然后每人每次提交到自己的分支上，過一段時間之后（不能太久）有一個人去合並分支。然后所有人更新自己的數據庫的master分支，使之跟服務器上的master分支同步。
2、這樣服務器會有非常多的版本信息，集合了每個人的版本信息。
過了一段時間之后，例如有里程碑的出現。再由一個人把所有改動打補丁到最終服務器上。這樣最終服務器的版本信息就會很精練。
3、當我們的服務器無限膨脹到一定程度的時候我們可以把它刪除，然后用最終服務器上的一個版本作為起始版本。