考慮到CVS的一些局限性，最近和同事在公司推行Git。
其實(shí)，如果推行SVN的化，可能推行的難度會降低很多。不過lark說既然推行一個(gè)新的版本管理工具，總要花費(fèi)一定的時(shí)間進(jìn)行培訓(xùn)、部署、轉(zhuǎn)換。而推行Git和SVN的代價(jià)不如想象中差距那么大。因此，不如就多花些精力推行Git ， 可以帶來更多的好處。 這個(gè)想法說服了我。 然后就開始籌備了。 我發(fā)現(xiàn)網(wǎng)上很多git教程對一些基礎(chǔ)命令（比如git-reset）的介紹還是不夠清楚。另外，介紹git1.5的少，介紹git1.4的多。此外，對于如何基于Git合作開發(fā)，介紹的內(nèi)容也是少之又少。因此，決定寫一份教程，以減少在公司推廣Git的培訓(xùn)代價(jià)。
其實(shí)我也是一個(gè)Git的新手。 寫這份教程也是我自己學(xué)習(xí)和摸索git的過程，其中基于Git進(jìn)行合作開發(fā)的模式參考了CVS，應(yīng)該是很初級的合作模式。但是當(dāng)前自己也只能做到這一步了。 教程所述都是自己通過試驗(yàn)驗(yàn)證的。至少可以滿足公司基本的合作開發(fā)。教程寫完后，謝欣說可以放到blog與大家共享。我覺得是個(gè)不錯(cuò)的主意。一方面我覺得這個(gè)文檔應(yīng)該可以給git的新手一些幫助，另一方面也歡迎git的大牛指點(diǎn)。 這里要感謝《Git 中文教程》的作者。還有概述中關(guān)于git的優(yōu)點(diǎn)描述拷貝了網(wǎng)絡(luò)上某位大牛的原話，但是拷貝的出處也是轉(zhuǎn)載的，就在這里謝謝那位我不知名大牛了。
Git下載： http://elephantinaurance.com/soft/30724.html
下面就開始了。
1. 概述
對于軟件版本管理工具，酷訊決定摒棄CVS而轉(zhuǎn)向Git了。
為什么要選擇Git？ 你真正學(xué)會使用Git時(shí)， 你就會覺得這個(gè)問題的回答是非常自然的。然而當(dāng)真正需要用文字來回答時(shí)，卻覺得文字好像不是那么夠用。 咳，該則么回答呢？
其實(shí)，關(guān)鍵的問題不在于如何回答這個(gè)問題。 問題的關(guān)鍵是公司已經(jīng)決定使用它了。那么，我們的程序員們！ 請開動(dòng)你們的瀏覽器，請拿出你的搜索引擎工具，去自己發(fā)掘答案吧。在這里，我只能給你們一個(gè)最朦朧的感覺。
Git和 CVS、SVN不同，是一個(gè)分布式的源代碼管理工具。Linux內(nèi)核的代碼就是用Git管理的。它很強(qiáng)，也很快。它給我們帶來的直接好處有：
1. 傻瓜都會的初始化，git init, git commit -a, 就完了。對于隨便寫兩行代碼就要放到代碼管理工具里的人來說，再合適不過。也可以拿git做備份系統(tǒng)，或者同步兩臺機(jī)器的文檔，都很方便。
2. 絕大部分操作在本地完成，不用和集中的代碼管理服務(wù)器交互，終于可以隨時(shí)隨地大膽地check in代碼了。 只有最終完成的版本才需要向一個(gè)中心的集中的代碼管理服務(wù)器提交。
3. 每次提交都會對所有代碼創(chuàng)建一個(gè)唯一的commit id。不像CVS那樣都是對單個(gè)文件分別進(jìn)行版本的更改。所以你可以一次性將某次提交前的所有代碼check出來，而不用考慮到底提交過那些文件。（其實(shí)SVN也可以做到這點(diǎn)）
4. branch管理容易多了，無論是建立新的branch，還是在branch之間切換都一條命令完成，不需要建立多余的目錄。
5. branch之間merge時(shí)，不僅代碼會merge在一起，check in歷史也會保留，這點(diǎn)非常重要。
6. … 太多了
當(dāng)然，Git也會帶給我們一些困難，首先，你想要使用好git，就要真正明白它的原理，理解它的觀念， 對以那些CVS的熟手來說，改變你已經(jīng)固有的純集中式源代碼管理的觀念尤為重要，同時(shí)也會讓你覺得有些困難。在使用git的初期，你可能會覺得有些困難，但等你逐漸明白它時(shí)，你絕對會喜歡上它。這是一定的，就像我問你“喜歡一個(gè)溫吞如水、毫無感覺的主婦，還是喜歡一個(gè)奔放如火，讓你愛的癡狂恨的牙癢的情人”一樣毋庸置疑。
下面，就讓我們進(jìn)入學(xué)習(xí)Git之旅…
請記住，這只是一個(gè)非常簡單而且初級的教程， 想要成為git的專家，需要各位同事不斷的自己深入挖掘。
2. Git基礎(chǔ)命令
2.1 創(chuàng)建Git庫—git-init
你們曾經(jīng)創(chuàng)建過CVS的庫么？應(yīng)該很少有人操作過吧？因?yàn)楹芏嗳硕际菑腃VS庫里checkout代碼。同樣，在合作開發(fā)中，如果你不是一個(gè)代碼模塊的發(fā)起者，也不會使用到這個(gè)命令，更多的是使用git-clone（見2.7節(jié)）。 但是，如果你想個(gè)人開發(fā)一個(gè)小模塊，并暫時(shí)用代碼管理工具管理起來（其實(shí)我就常這么做，至少很多個(gè)人開發(fā)過程都可以保留下來，以便備份和恢復(fù)），創(chuàng)建一個(gè)Git庫是很容易和方便的。
對于酷訊來說，當(dāng)一個(gè)代碼的Git庫創(chuàng)建后，會添加代碼文件到庫里，并將這個(gè)庫放到公司一個(gè)專門用來進(jìn)行代碼管理的服務(wù)器上，使大家可以在以后clone（不明白？沒關(guān)系，繼續(xù)往后看就明白了）它。對于個(gè)人來說，你可以隨便將這個(gè)庫放到哪里，只要你能訪問的到就行。
創(chuàng)建一個(gè)Git庫是很容易和方便的，只要用命令 git-init 就可以了。在Git1.4之前（包括git1.4）的版本，這個(gè)命令是git-init。
a) $ mkdir dir
b) $ cd dir
c) $ git-init
這樣，一個(gè)空的版本庫就創(chuàng)建好了，并在當(dāng)前目錄中創(chuàng)建一個(gè)叫 .git 的子目錄。以后，所以的文件變化信息都會保存到這個(gè)目錄下，而不像CVS那樣，會在每個(gè)目錄和子目錄下都創(chuàng)建一個(gè)討厭的CVS目錄。
在.git目錄下有一個(gè)config文件， 需要我們添加一下個(gè)人信息后才能使用。否則我們不能對其中添加和修改任何文件。
原始的config文件是這樣的，
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
我們需要加入
[user]
name = xxx
emai= xxx@kuxun.cn
現(xiàn)在已經(jīng)創(chuàng)建好了一個(gè) git 版本庫，但是它是空的，還不能做任何事情，下一步就是怎么向版本庫中添加文件了。如果希望忽略某些文件，需要在git庫根目錄下添加. gitignore文件。
2.2 一條重要的命令 -- git-update-index
在介紹如何向git庫中添加文件前，不得不先介紹git-update-index命令。這條命令可能會使很多熟悉CVS的用戶疑惑， 一般來說，我們向一個(gè)源代碼管理庫提交代碼的更改，都會抽象為以下的動(dòng)作：更改文件；向源碼管理系統(tǒng)標(biāo)識變化；提交。比如從一個(gè)CVS庫里刪除一個(gè)文件，需要先刪除文件，然后cvs delete； 最后cvs commit。
因此， git-update-index就是向源碼管理系統(tǒng)標(biāo)識文件變化的一個(gè)抽象操作。說的簡要一些，git-update-index命令就是通知git庫有文件的狀態(tài)發(fā)生了變化（新添、修改、刪除等待）。這條命令在早期的git版本中是非常常用的。 在新的git版本（1.5版本及以后）已經(jīng)被其它命令包裝起來，并且不推薦使用了。
git-update-index最常用的方式有以下兩種，更多功能請man git-update-index。
方法一：git-update-index --add 文件名列表。 如果文件存在，則這條命令是向git庫標(biāo)識該文件發(fā)生過變化（無論是否該文件確實(shí)被修改過），如果文件不存在，則這條命令是向git庫表示需要加入一個(gè)新文件。
方法二： git-update-index --force-remove 文件名列表。 這表示向git庫表示喲啊從庫中刪除文件。無論該文件是否已經(jīng)被刪除，這條命令僅僅是通知git庫要從庫中刪除這些文件。這些文件都不會受影響。
因此，git-update-index僅僅是向git庫起到一個(gè)通知和標(biāo)識的作用，并不會操作具體的文件。
2.3 向git庫中添加或刪除文件 – git-add、git-rm
其實(shí)，說使用git-add命令向git庫里添加文件是不對的， 或者說至少是不全面的。git-add 命令的本質(zhì)是命令"git-update-index --add” 的一個(gè)包裝。因此，git-add除了可以添加文件，還可以標(biāo)識文件修改。在調(diào)用了git-add后，才可以做commit操作。git-rm 也是一樣， 它是git-update-index --force-remove的一個(gè)包裝。
對于git-add來說， 如果在一個(gè)目錄下調(diào)用了git-add * ,則默認(rèn)是遞歸將子目錄中所有文件都add到git庫中。對于git-rm來說，也是一樣。 這點(diǎn)和CVS有較大區(qū)別。
此外，我們還可以通過命令git-ls-files來查看當(dāng)前的git庫中有那些文件。
2.4 查看版本庫狀態(tài)—git-status
通過該命令，我們可以查看版本庫的狀態(tài)�？梢缘弥切┪募l(fā)生了變化，那些文件還沒有添加到git庫中等等。 建議每次commit前都要通過該命令確認(rèn)庫狀態(tài)。以避免誤操作。
其總，最常見的誤操作是， 修改了一個(gè)文件， 沒有調(diào)用git-add通知git庫該文件已經(jīng)發(fā)生了變化就直接調(diào)用commit操作， 從而導(dǎo)致該文件并沒有真正的提交。如果這時(shí)如果開發(fā)者以為已經(jīng)提交了該文件，就繼續(xù)修改甚至刪除這個(gè)文件，那么修改的內(nèi)容就沒有通過版本管理起來。如果每次在提交前，使用git-status查看一下，就可以發(fā)現(xiàn)這種錯(cuò)誤。因此，如果調(diào)用了git-status命令，一定要格外注意那些提示為“Changed but not updated:”的文件。 這些文件都是與上次commit相比發(fā)生了變化，但是卻沒有通過git-add標(biāo)識的文件。
2.5 向版本庫提交變化 – git-commit
直接調(diào)用git-commit命令，會提示填寫注釋。也可以通過如下方式在命令行就填寫提交注釋：git-commit -m "Initial commit of gittutor reposistory"。 注意，和CVS不同，git的提交注釋必須不能為空。否則就會提交失敗。
git-commit還有一個(gè) –a的參數(shù)，可以將那些沒有通過git-add標(biāo)識的變化一并強(qiáng)行提交，但是不建議使用這種方式。
每一次提交，git就會為全局代碼建立一個(gè)唯一的commit標(biāo)識代碼，用戶可以通過git-revert命令恢復(fù)到任意一次提交時(shí)的代碼。 這比CVS不同文件有不同的版本呢號管理可方便多了。（和SVN類似）
如果提交前，想看看具體那些文件發(fā)生變化，可以通過git-diff來查看， 不過這個(gè)命令的輸出并不友好。因此建議用別的工具來實(shí)現(xiàn)該功能。在提交后，還可以通過git-log命令來查看提交記錄。
2.6 分支管理 – git-branch
我們迎來了git最強(qiáng)大，也是比CVS、SVN強(qiáng)大的多的功能 — 分支管理。
大概每個(gè)程序員都會經(jīng)常遇到這樣的情況：
1. 需要立刻放下手頭的工作，去修改曾經(jīng)一個(gè)版本的bug并上線，然后再繼續(xù)當(dāng)?shù)墓ぷ鳌?br />2. 本想向中心庫commit一個(gè)重要修改，但是由于需要經(jīng)常備份代碼，最終不得不頻繁的向中心庫commit。從而導(dǎo)致大量無用的commit信息被保留在中心庫中。
3. 將一次修改提交同事進(jìn)行code review， 但是由于同事code review比較慢， 得到反饋時(shí)，自己的代碼已經(jīng)發(fā)生了變化，從而倒是合并異常困難
這些場景，如果用CVS或者SVN來解決，雖說不一定解決不了，但過程之繁瑣，之復(fù)雜，肯定另所有人都有生不如死的感覺吧！究其關(guān)鍵，就是CVS或者SNV的branch管理太復(fù)雜，基本不具可用性。
在 git 版本庫中創(chuàng)建分支的成本幾乎為零，所以，不必吝嗇多創(chuàng)建幾個(gè)分支。當(dāng)?shù)谝淮螆?zhí)行g(shù)it-init時(shí)，系統(tǒng)就會創(chuàng)建一個(gè)名為”master”的分支。 而其它分支則通過手工創(chuàng)建。下面列舉一些常見的分支策略，這些策略相信會對你的日常開發(fā)帶來很大的便利。
1.創(chuàng)建一個(gè)屬于自己的個(gè)人工作分支，以避免對主分支 master 造成太多的干擾，也方便與他人交流協(xié)作。
2.當(dāng)進(jìn)行高風(fēng)險(xiǎn)的工作時(shí)，創(chuàng)建一個(gè)試驗(yàn)性的分支，扔掉一個(gè)爛攤子總比收拾一個(gè)爛攤子好得多。
3.合并別人的工作的時(shí)候，最好是創(chuàng)建一個(gè)臨時(shí)的分支用來合并，合并完成后在“fatch”到自己的分支（合并和fatch后面有講述，不明白就繼續(xù)往下看好了）
2.6.1 查看分支 – git-branch
調(diào)用git-branch可以查看程序中已經(jīng)存在的分支和當(dāng)前分支
2.6.2 創(chuàng)建分支 – git-branch 分支名
要?jiǎng)?chuàng)建一個(gè)分支，可以使用如下方法:
1. git-branch 分支名稱
2. git-checout –b 分支名
使用第一種方法，雖然創(chuàng)建了分支，但是不會將當(dāng)前工作分支切換到新創(chuàng)建的分支上，因此，還需要命令”git-checkout 分支名” 來切換， 而第二種方法不但創(chuàng)建了分支，還將當(dāng)前工作分支切換到了該分支上。
另外，需要注意，分支名稱是有可能出現(xiàn)重名的情況的， 比如說，我在master分支下創(chuàng)建了a和b兩個(gè)分支， 然后切換到b分支，在b分支下又創(chuàng)建了a和c分支。 這種操作是可以進(jìn)行的。 此時(shí)的a分支和master下的a分支實(shí)際上是兩個(gè)不同的分支。 因此，在實(shí)際使用時(shí)，不建議這樣的操作，這樣會帶來命名上的疑惑。
2.6.3 刪除分支 – git-branch –D
git-branch –D 分支名可以刪除分支，但是需要小心，刪除后，發(fā)生在該分支的所有變化都無法恢復(fù)。
2.6.4 切換分支 – git-checkout 分支名
如果分支已經(jīng)存在， 可以通過 git-checkout 分支名 來切換工作分支到該分支名
2.6.5 查看分支歷史 –git-show-branch
調(diào)用該命令可以查看分支歷史變化情況。 如：
* [dev1] d2
! [master] m2
--
* [dev1] d2
* [dev1^] d1
* [dev1~2] d1
*+ [master] m2
在上述例子中， “--”之上的兩行表示有兩個(gè)分支dev1和master， 且dev分支上最后一次提交的日志是“d2”,master分支上最后一次提交的日志是”m2”。 “--”之下的幾行表示了分支演化的歷史，其中 dev1表示發(fā)生在dev分支上的最后一次提交，dev^表示發(fā)生在dev分支上的倒數(shù)第二次提交。dev1~2表示發(fā)生在dev分支上的倒數(shù)第三次提交。
2.6.6 合并分支 – git-merge
git-merge的用法為：git-merge “some memo” 合并的目標(biāo)分支 合并的來源分支。如：
git-merge master dev1~2
如果合并有沖突，git會由提示，當(dāng)前，git-merge已經(jīng)很少用了， 用git-pull來替代了。
用法為：git-pull 合并的目標(biāo)分支 合并的來源分支。 如git-pull . dev1^
2.7 遠(yuǎn)程獲取一個(gè)git庫 git-clone
在2.1節(jié)提到過，如果你不是一個(gè)代碼模塊的發(fā)起者，也不會使用到git-init命令，而是更多的是使用git-clone。通過這個(gè)命令，你可以從遠(yuǎn)端完整獲取一個(gè)git庫，并可以通過一些命令和遠(yuǎn)端的git交互。
基于git的代碼管理的組織結(jié)構(gòu)，往往形成一個(gè)樹狀結(jié)構(gòu)，開發(fā)者一般從某個(gè)代碼模塊的管理者的git庫通過git-clone取得開發(fā)環(huán)境，在本地迭代開發(fā)后，再提交給該模塊的管理者，該模塊的管理者檢查這些提交并將代碼合并到自己的庫中，并向更高一級的代碼管理者提交自己的模塊代碼。
對于酷訊來說，公司會有一個(gè)中心的git庫， 大家在開發(fā)時(shí)，都是從中心庫git-clone獲取最新代碼。
git-clone的使用方法如下： git-clone [ssh://]username@ipaddr:path。 其中， “ssh://”可選，也有別的獲取方式，如rsync。 Path是遠(yuǎn)端git的根路徑，也叫repository。
通過git-clone獲取遠(yuǎn)端git庫后，.git/config中的開發(fā)者信息不會被一起clone過來。仍然需要為.git/config文件添加開發(fā)者信息。此外，開發(fā)者還需要自己添加. gitignore文件
另外，通過git-clone獲取的遠(yuǎn)端git庫，只包含了遠(yuǎn)端git庫的當(dāng)前工作分支。如果想獲取其它分支信息，需要使用”git-branch –r” 來查看， 如果需要將遠(yuǎn)程的其它分支代碼也獲取過來，可以使用命令” git checkout -b 本地分支名 遠(yuǎn)程分支名”，其中，遠(yuǎn)程分支名為git-branch –r所列出的分支名， 一般是諸如“origin/分支名”的樣子。如果本地分支名已經(jīng)存在， 則不需要“-b”參數(shù)。
2.8 從遠(yuǎn)程獲取一個(gè)git分支 – git-pull
與git-clone不同， git-pull可以從任意一個(gè)git庫獲取某個(gè)分支的內(nèi)容。用法如下：
git-pull username@ipaddr: 遠(yuǎn)端repository名 遠(yuǎn)端分支名:本地分支名。這條命令將從遠(yuǎn)端git庫的遠(yuǎn)端分支名獲取到本地git庫的一個(gè)本地分支中。其中，如果不寫本地分支名，則默認(rèn)pull到本地當(dāng)前分支。
需要注意的是，git-pull也可以用來合并分支。 和git-merge的作用相同。 因此，如果你的本地分支已經(jīng)有內(nèi)容，則git-pull會合并這些文件，如果有沖突會報(bào)警。
2.9 將本地分支內(nèi)容提交到遠(yuǎn)端分支 – git-push
git-push和git-pull正好想反，是將本地某個(gè)分支的內(nèi)容提交到遠(yuǎn)端某個(gè)分支上。用法：
git-push username@ipaddr: 遠(yuǎn)端repository名 本地分支名:遠(yuǎn)端分支名。這條命令將本地git庫的一個(gè)本地分支push到遠(yuǎn)端git庫的遠(yuǎn)端分支名中。
需要格外注意的是，git-push好像不會自動(dòng)合并文件。這點(diǎn)我的試驗(yàn)表明是這樣，但我不能確認(rèn)是否是我用錯(cuò)了。因此，如果git-push時(shí)，發(fā)生了沖突，就會被后push的文件內(nèi)容強(qiáng)行覆蓋，而且沒有什么提示。 這在合作開發(fā)時(shí)是很危險(xiǎn)的事情。
2.10 庫的逆轉(zhuǎn)與恢復(fù) – git-reset
庫的逆轉(zhuǎn)與恢復(fù)除了用來進(jìn)行一些廢棄的研發(fā)代碼的重置外，還有一個(gè)重要的作用。比如我們從遠(yuǎn)程clone了一個(gè)代碼庫，在本地開發(fā)后，準(zhǔn)備提交回遠(yuǎn)程。但是本地代碼庫在開發(fā)時(shí)，有功能性的commit，也有出于備份目的的commit等等�？傊琧ommit的日志中有大量無用log，我們并不想把這些log在提交回遠(yuǎn)程時(shí)也提交到庫中。 因此，就要用到git-reset。
Git-reset的概念比較復(fù)雜。它的命令形式：git-reset [--mixed | --soft | --hard] [<commit-ish>]
命令的選項(xiàng)：
--mixed
這個(gè)是默認(rèn)的選項(xiàng)。 如git-reset [--mixed] dev1^(dev1^的定義可以參見2.6.5)。它的作用僅是重置分支狀態(tài)到dev1^, 但是卻不改變?nèi)魏喂ぷ魑募膬?nèi)容。即，從dev1^到dev1的所有文件變化都保留了，但是dev1^到dev1之間的所有commit日志都被清除了，而且，發(fā)生變化的文件內(nèi)容也沒有通過git-add標(biāo)識，如果您要重新commit，還需要對變化的文件做一次git-add。 這樣，commit后，就得到了一份非常干凈的提交記錄。
--soft
相當(dāng)于做了git-reset –mixed，后，又對變化的文件做了git-add。如果用了該選項(xiàng)， 就可以直接commit了。
--hard
這個(gè)命令就會導(dǎo)致所有信息的回退， 包括文件內(nèi)容。 一般只有在重置廢棄代碼時(shí)，才用它。 執(zhí)行后，文件內(nèi)容也無法恢復(fù)回來了。
2.11 更多的操作
之前的10節(jié)只簡要介紹了git的基本命令，更多的細(xì)節(jié)可以去linux下man git的文檔。此外，http://www.linuxsir.org/main/doc/git/gittutorcn.htm 也有不少更詳細(xì)的介紹。
3. 基于git的合作開發(fā)
對于酷訊來說，當(dāng)我們采用了Git，如何進(jìn)行合作開發(fā)呢？ 具體步驟如下：
3.1 獲取最新代碼
酷訊會準(zhǔn)備一個(gè)中心git代碼庫。首先，我們將整理好的代碼分模塊在git中心庫中建立git庫。并將文件add到中心庫中。 接下來，開發(fā)者通過git-clone將代碼從中心庫clone到本地開發(fā)環(huán)境。
對于較大的項(xiàng)目，我們還建議每個(gè)組選擇一個(gè)負(fù)責(zé)人，由這個(gè)負(fù)責(zé)人負(fù)責(zé)從中心庫獲取和更新最新的代碼，其它開發(fā)者從這個(gè)負(fù)責(zé)人的git代碼庫中clone代碼。此時(shí)，對開發(fā)者來說，這個(gè)負(fù)責(zé)人的git庫就是中心庫了。
3.2 開發(fā)者在本地進(jìn)行迭代開發(fā)
當(dāng)用戶將代碼clone到本地后， 就可以進(jìn)行本地的迭代開發(fā)，建議用戶不要在master分支上開發(fā)，而是建立一個(gè)開發(fā)分支進(jìn)行開發(fā)。 在本地開發(fā)中，用戶可以隨意的創(chuàng)建臨時(shí)分支，隨意commit。
3.3 開發(fā)者請其它同事進(jìn)行code review
當(dāng)本地開發(fā)完畢，可以請其它同事進(jìn)行code review。過程為：
1. user2通通過git-pull命令，將開發(fā)者(user1)的開發(fā)分支（dev）pull到user2本地的一個(gè)tmp分支，并切換工作分支到該分支上進(jìn)行code review。
2. 完成code review后， user2切換回其原有開發(fā)分支繼續(xù)開發(fā)，并告知user1已經(jīng)修改完畢。
3. User1將user2的tmp分支git-pull到本地tmp分支，并和dev分支進(jìn)行merge。最終得到一個(gè)code review后的dev分支。
當(dāng)然，user2也可以直接坐在user1旁邊在他的代碼上進(jìn)行review。而不需要走上述步驟。（圖中第7步，不是git-pull,而是直接在dev分支上和user1邊review邊modify）
3.4 和中心庫進(jìn)行代碼合并
使用過CVS的人都知道， 在commit之前，都要做一次cvs update，以避免和中心庫沖突。Git也是如此。
現(xiàn)在我們已經(jīng)經(jīng)過了code review， 準(zhǔn)備向中心庫提交變化了， 在開發(fā)的這段時(shí)間，也許中心庫發(fā)生了變化， 因此，我們需要在向中心庫提交前，再次將中心庫的master分支git-pull到本地的master分支上。并且和dev分支做合并。最終，將合并的代碼放入master分支。
如果開發(fā)過程提交日志過多，可以考慮參照2.10節(jié)的介紹做一次git-reset。
此外，如果發(fā)現(xiàn)合并過程變化非常多， 出于代碼質(zhì)量考慮，建議再做一次code review
3.5 提交代碼到中心庫
此時(shí)，已經(jīng)完全準(zhǔn)備好提交最終的代碼了。 通過git-push就可以了。
3.6 合作流程總結(jié)
大家可以看到，使用git進(jìn)行合作開發(fā)，這一過程和CVS有很多相似性，同時(shí)，增強(qiáng)了以下幾個(gè)環(huán)節(jié)：
1. 開發(fā)者在本地進(jìn)行迭代開發(fā)，可以經(jīng)常的做commit操作且不會影響他人。 而且即使不在線也可以進(jìn)行開發(fā)。只需要最后向中心庫提交一次即可。
2. 大家都知道，如果CVS管理代碼，由于我們會常常做commit操作。但是在commit之前cvs update時(shí)常會遇到將中心庫上的其它最新代碼checkout下來的情況，此時(shí)，一旦出現(xiàn)問題，就很難確認(rèn)到底是自己開發(fā)的bug還是其它用戶的代碼帶來了影響。 而使用git則避免了用戶間的開發(fā)互相影響。
3. 更有利于在代碼提交前做code review。 以往用cvs， 都是代碼提交后才做code view。如果發(fā)生問題， 也無法避免服務(wù)器上有不好的代碼。 但是用git， 真正向中心庫commit前，都是在本地開發(fā)，可以方便的進(jìn)行code review， 然后才提交到中心庫。更有利于代碼質(zhì)量。而且， 大家應(yīng)該可以感到，使用git的過程中，更容易對代碼進(jìn)行code review，因?yàn)橛绊懸蛩馗 ?br />4. 創(chuàng)建多分支，更容易在開發(fā)中進(jìn)行多種工作，而使工作間不會互相影響。 比如user2對user1的代碼進(jìn)行code review時(shí)，就可以非常方便的保留當(dāng)時(shí)的開發(fā)現(xiàn)場，并切換到user1的代碼分支，在code review完畢后，也可以非常方便的切換會曾經(jīng)被中斷的工作現(xiàn)場。
誠然，帶來這些好處的同時(shí)，確實(shí)也使得操作比CVS復(fù)雜了一些。但我們覺得和前面所能獲得的好處相比，這些麻煩是值得的。 當(dāng)大家用慣了之后會發(fā)現(xiàn)，這并不增加多大的復(fù)雜性， 而且開發(fā)流程會更加自然。
請大家多動(dòng)手，多嘗試! 去體驗(yàn)git的魅力所在吧！let’s enjoy it!
喜歡 
頂
難過
囧
圍觀
無聊
