上一篇主要介紹了git 的基本操作，這一章主要講解git 在實際項目開發中的使用。很多時候我們是多個人同時爲做一件事情而努力，如何有效化解多人協同運作過程中出現的種種矛盾是相當重要的。實踐證明，Git可以很好的勝任此類任務，這也是我們要在實驗室內部推廣Git應用的主要原因。
兩個人如何協同 ：
小明與小強是本節的兩位主角。現在假設小明開始着手開發一個APP，並按照 前一篇所講述的Git基本用法將APP納於Git的管理之下。但是，很快小明就 發現了僅憑個人之力很難項目規定期限內完成這項工作，因此他邀請小強來參與APP，故事就這樣開始了。
cd work
git clone [email protected]:~/work/appgit-clone可利用各種網絡協議訪問遠端機器中的Git倉庫，從中導出完整的 工作樹到本地。
一個階段之後，二人均將所做的工作不斷地提交到各自的Git倉庫中，直至他 們覺得有必要將各自所做的工作合併起來之後再進行新的開發階段。由於小明作爲主要開發者，二人的工作在他的機器上進行合併是比較自然的。
爲實現與小強的工作合併，小明執行了以下操作：
cd ~/work/app
git pull [email protected]:~/work/appgit-pull命令可將屬於同一項目的遠端倉庫與同樣屬於同一項目的本地倉庫進行合併，它包含了兩個操作：從遠端倉庫中取出更新版本，然後合併到本地倉庫。上述命令可在小明的app倉庫中完成對小強機器上的app倉庫的合併。
如何解決倉庫合併衝突 :
現在假設小明和小強在各自的工作樹中對同一份文件foo.txt進行了修改，造成了衝突。需求進行了手工合併。最後，小明將合併處理結果提交到倉庫中，即完
成了重疊衝突的合併問題的解決。
三人以至更多人如何協同:
上述模式主要講了兩人的主次關係，多若引入多人時，小明需要一一取回他們倉庫，然後更新，才能完成版本的合併。 這樣小明就會疲於應付。因此小明希望其他人能爲他分擔一些版本合併問題。
Git提供了git-pull的對偶命令，即git-push。顧名思義，git-pull命令負責從遠端倉庫取回版本更新，而git-push可將本地版本更新推送到遠端倉庫中。利用git-pull與git-push命令，那麼在一個協同週期之內，除了小明之外之外，其餘多人的項目開發流程大致如下：
git clone [email protected]:~/work/m2ge
...項目開發...
git add ./demo.php
git commit
git pull
...解決版本合併問題 ...
git push 在一個協同週期內，小明對app倉庫的管理工作相當於管理一份他個人項目一般，因爲app庫是位於他的機器上，他是不需要git-pull與git-push的。
項目中協同開發優化：
上述所給出的三人及三人以上的協同工作模式有些不合理，譬如小明過於 特殊，別人都要git-pull與git-push，唯獨他不需要。現在要剝奪他的這一特權，最有效的辦法就是將app倉庫建立在一臺單獨的服務器上。
首先，小明通過SSH登錄到服務器，尋找合適位置，建立app.git目錄，譬如/project/app.git，然後初始化一個空倉庫，以此作爲app倉庫：
mkdir -p ~/project/app.git
cd ~/project/app.git
git--bare init --shared
上述操作中，git-init命令的--bare選項可以讓app.git目錄等價於一個倉庫。也就是說，app.git本來是一個工作樹，但是--bare選項將本應當存放在app.git/.git中的倉庫內容全部放置在app.git目錄下，就好像倉庫完全的裸 露在工作樹中，所以稱之爲赤裸的倉庫。
然後，小明將自己機器上已經接受Git管理的app倉庫推送到服務器端的app.git倉庫：
cd ~/work/app
git push [email protected]:~/project/app.git master
上述git-push命令中出現的master參數的含義將在下面講述，此處可略過不談。現在，大家已經得到了app倉庫的最初版本，並且可以使用git-clone命令在本地創建工作目錄：
git clone [email protected]:~/project/app.git 之後，我們就可以開始一個又一個協同週期，服務器上的app.git倉庫將會逐次記錄着每位協同開發者的版本更新提交，此基本過程可參考上一節所述內容來理解。
項目分支管理：
git最爲世人稱道的就是它那強大的項目分支管理功能，現在較爲流行的版本控制系統，諸如CVS、SVN等，雖然也提供了項目分支管理功能，但是可用性極低。對於Git而言，管理多個項目分支如探囊取物耳。本章主要講述Git的項目分支管理的基本知識以及如何利用這一功能形成更有章法的項目協同開發模式。
如何產生項目分支 ：
前兩章所講內容未有提及項目分支問題，但事實上是有一個分支存在的，那就是master分支（主分支），該分支是由Git自動產生的。在此之前，我們針對項目版本的各種操作都是在主分支上進行的，只是我們未察覺它的存在而已。Git可以輕鬆地產生新的項目分支，譬如下面操作可添加一個名曰“local”的新的項目分支：
git branch local 對於新產生的local分支，初始時是完全等同於主分支的。但是，在local分支所進行的所有版本更新工作都不影響主分支，這意味着作爲項目的參與者，可以在local中開始各種各樣的更新嘗試。查看項目倉庫中存在多少分支，可直接使用git-branch命令，譬如使用該命令查看我的M2Doc項目分支列表：
git branch
local
*master 在上述操作輸出結果中，若分支名之前存在*符號，表示此分支爲當前分支。其實Git各分支不存在尊卑之別，只存在哪個分支是當前分支的區別。爲了某種良好的秩序，很多人默認是將master分支視爲主分支，本文也將沿用這一潛在規則。
由上述操作輸出的分支列表可以看出，雖然使用git-branch命令產生了local分支，但是Git不會自動將當前分支切換到local下。可使用git-checkout命令實現分支切換，下面操作將當前分支切換爲前文所產生的local分支：
git checkout local分支的合併 ：
我們產生了local分支，並在該分支下進行了諸多修改與數次的版本更新提交，但是該如何將這一分支的最終狀態提交到master分支中呢？git-merge命令可實現兩個分支的合併。譬如我們將local分支與master分支。合併，操作如下：
git checkout master #將當前分支切換爲master
git merge local #將local分支與當前分支合併 當一個分支檢查無誤並且與master分支成功合併完畢後，那麼這一分支基本上就沒有存在的必要性了，可以刪除掉：
git branch -d local注意，git-branch的-d選項只能刪除已經參與了合併的分支，對於未有合併的分支是無法刪除的。如果想不問青紅皁白地刪除一個分支，可以使用git-branch的 -D選項。
APP協同開發模式：
現在來討論一下如何基於Git項目分支管理功能實現更爲穩健、高效的APP庫的協同開發機制。
一臺單獨服務器上已經建立了app倉庫。現在以小明作爲主角，看一看他圍繞app開發工作的一天中的工作過程。
git pull #更新自己機器上的工作樹
git log #查看其他成員的版本更新
git branch merchandise #新建一個merchandies 分支
git checkout merchandise #切換到該分支
……在新分支上開發一天的工作
git checkout #切換到主分支
git branch #查看當前分支
git merge merchandise #合併merchantdies上的更新
git branch -d merchandise #刪除一合併的分支
git pull #獲取其他成員在公共倉庫的更新
……若有衝突解決衝突
git push #將更新推送到公共倉庫
至此，對於我們而言，在基於Git的app協同開發過程中，引入分支管理功能，可有效防止因個人操作不當而導致向服務器app倉庫提交太多的髒數據。另外，也有效保持了本地項目主分支的乾淨，避免了頻繁git-clone服務器端的M2GE倉庫來恢復本地的項目主分支。
小技巧：
如果你在項目中，某個文件比較私有，不想被push到中心版本庫。例如數據庫連接配置（開發環境和線上環境不同）。你可以將其忽略！
git update-index --assume-unchanged <file>又或者你想讓上述文件重新回到版本控制下你可以執行下面的命令：
git update-index --no-assume-unchanged <file>
