指導老師：邵志遠
作者： 卓達城
郵箱： [email protected]單位： 華中科技大學服務計算技術與系統/集羣與網格計算實驗室
簡介： 作者是華中科技大學2010級計算機學院計算機系統結構專業研究生
一、簡介：
網上找到的git的中文資料，大部分是講git的命令的使用，對於git的工作流程和如何實現團隊合作的介紹少之又少，特別是對於團隊代碼庫管理者的文檔，幾乎沒有，這份文檔將從開發者和管理者兩方面介紹如何使用git進行團隊合作開發。
二、git和svn的差異
git和svn最大的差異在於git是分佈式的管理方式而svn是集中式的管理方式。如果不習慣用代碼管理工具，可能比較難理解分佈式管理和集中式管理的概念。下面介紹兩種工具的工作流程（團隊開發），通過閱讀下面的工作流程，你將會很好的理解以上兩個概念。
集中式管理的工作流程如下圖（圖2.1）：
集中式代碼管理的核心是服務器,所有開發者在開始新一天的工作之前必須從服務器獲取代碼,然後開發,最後解決衝突,提交。所有的版本信息都放在服務器上。如果脫離了服務器,開發者基本上是不可以工作。下面舉例說明:
開始新一天的工作:
1:從服務器下載項目組最新代碼。
2:進入自己的分支,進行工作,每隔一個小時向服務器自己的分支提交一次代碼(很多人都有這個習慣。因爲有時候自己對代碼改來改去,最後又想還原到前一個小時的版本,或者看看前一個小時自己修改了那些代碼,就需要這樣做了)。
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:向公共服務器提交結果,然後通知所有開發人員。
優點:
適合分佈式開發,強調個體。
公共服務器壓力和數據量都不會太大。
速度快、靈活。
任意兩個開發者之間可以很容易的解決衝突。
離線工作。
缺點:
資料少(起碼中文資料很少)。
學習週期相對而言比較長。
不符合常規思維。
代碼保密性差,一旦開發者把整個庫克隆下來就可以完全公開所有代碼和版本信息。
三、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
查看幫助,還有幾個無關緊要的命令,請自己查看幫助。
四、git 開發模式
1:大項目開發模式(如圖 4.1)(不適合我們實驗室使用)
對於項目負責人
1:初始化
對於最終項目負責人:
使用 git init --bare 在公共服務器上建立一個空數據庫,在自己的機器上通過
獲得數據庫(這裏需要設置一下訪問權限,由於 git 沒有提供權限管理功能,所以要通過 ssh設置,具體是對下一級子項目經理可讀不可寫,對自己可讀可寫)。
新建一些必要的文件夾和文件在放到自己的數據庫上
然後使用
提交到公共服務器上,作爲原始版本。
告訴下級公共服務器的地址。
對於子項目負責人:
在子公共服務器上克隆一個數據庫
設置訪問權限,對下級可讀不可寫,對自己可讀可寫。
在自己的計算機中克隆一個數據庫
告訴下級子公共服務器地址。
對於最底層的開發人員:
在上級公共服務器中克隆一個數據庫
2:開展工作
對於最終項目負責人
收來自下級的郵件
在自己的數據庫上建分支,並轉到分支上
重複上述步驟,直到所有補丁打完。
如果發現在合併分支的時候發現有些衝突需要下級項目負責人協助解決的話,可以通知下級項目負責人。
對於子項目負責人:
如果上級項目負責人需要他們之間合作解決某些衝突,他們可以通過
解決衝突。
如果上級項目負責人沒有要求合作解決衝突,那項目負責人應該做以下事情:
然後項目負責人就開始接收郵件,然後打補丁
重複上述工作,直到補丁全部打完。
下面是向上級提交更新的過程
對於最底層的開發人員:
如果上級要求解決衝突,同樣是要解決衝突,然後再提交補丁
如果不用,就從上級服務器更新
然後建分支,並開發代碼
然後是向上級提交代碼
以上就是 git 在大項目開發中的應用。
五、通過 ssh 進行權限管理
這個問題在第一版暫時不講。目的是規定哪些人可以對服務器做什麼事情(讀?寫?)