這篇文章將從開發者和管理者兩方面介紹如何使用git進行團隊合做開發。 git
1.git 和svn的差別 數據庫
git和svn 最大的差別在於git是分佈式的管理方式而svn是集中式的管理方式。若是不習慣用代碼管理工具,可能比較難理解分佈式管理和集中式管理的概念。下面介紹兩種工具的工做流程(團隊開發),經過閱讀下面的工做流程,你將會很好的理解以上兩個概念。 安全
集中式管理的工做流程以下圖(圖2.1): 服務器
集中式代碼管理的核心是服務器,全部開發者在開始新一天的工做以前必須從服務器獲取代碼,而後開發,最後解決衝突,提交。全部的版本信息都放在服務器上。若是脫離了服務器,開發者基本上是不能夠工做。下面舉例說明: 架構
開始新一天的工做: app
1:從服務器下載項目組最新代碼。 ssh
2:進入本身的分支,進行工做,每隔1個小時向服務器本身的分支提交一次代碼(不少人都有這個習慣。由於有時候本身對代碼改來改去,最後又想還原到前一個小時的版本,或者看看前一個小時本身修改了哪些代碼,就須要這樣作了)。 分佈式
3:下班時間快到了,把本身的分支合併到服務器主分支上,一天的工做完成,並反映給服務器。 svn
這就是經典的svn工做流程,從流程上看,有很多缺點,但也有優勢。 工具
缺點:
一、服務器壓力太大,數據庫容量暴增。
二、若是不能鏈接到服務器上,基本上不能夠工做,看上面第二步,若是服務器不能鏈接上,就不能提交,還原,對比等等。
三、不適合開源開發(開發人數很是很是多,可是Google app engine就是用svn的)。可是通常集中式管理的有很是明確的權限管理機制(例如分支訪問限制),能夠實現分層管理,從而很好的解決開發人數衆多的問題。
優勢:
一、管理方便,邏輯明確,符合通常人思惟習慣。
二、易於管理,集中式服務器更能保證安全性。
三、代碼一致性很是高。
四、適合開發人數很少的項目開發。
五、大部分軟件配置管理的大學教材都是使用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在大項目開發中的應用。
可是明顯是不適合咱們實驗室的。
緣由有三:
一、咱們學生中沒有專門的維護人員。
二、咱們學生中沒有對全局都很瞭解架構師。
三、咱們的老師能夠擔當此重任也只有咱們的老師有這樣的實力,可是老師太忙,沒時間天天作這些雜事。
因此咱們須要一種新的合做模式(一種沒有項目負責人的模式)。
這種模式對開發人員的素質要求很高。
合做模式以下圖(圖4.2):(適合咱們實驗室使用)
這種模式的開發流程以下: 一、由其中一個開發者這服務器上創建一個數據庫。 全部開發者均可以向數據庫提交和下載東西,這裏必須規定必定的時間間隔(一週或者一天)必須提交一次,否則之後解決衝突時是個大問題。 若是每一個人的開發耦合度很高,咱們可在服務器上創建分支,而後每人每次提交到本身的分支上,過一段時間以後(不能過久)有一我的去合併分支。而後全部人更新本身的數據庫的master分支,使之跟服務器上的master分支同步。 二、這樣服務器會有很是多的版本信息,集合了每一個人的版本信息。 過了一段時間以後,例若有里程碑的出現。再由一我的把全部改動打補丁到最終服務器上。這樣最終服務器的版本信息就會很精練。 三、當咱們的服務器無限膨脹到必定程度的時候咱們能夠把它刪除,而後用最終服務器上的一個版本做爲起始版本。