Git 作為版本控制系統(tǒng)，其主要功能就是團隊協(xié)作棉磨，成員之間必然就存在著數(shù)據(jù)交換江掩，而數(shù)據(jù)交換需要協(xié)議，Git 支持的協(xié)議包括：SSH乘瓤、GIT环形、HTTP、HTTPS 等衙傀。

在本篇抬吟，我們將模擬一個公共版本庫（想象為遠程服務器），多個不同的用戶工作環(huán)境（想象為在不同的主機上统抬，由不同的用戶進行操作）火本。

下面正式演示一個共享版本庫的搭建以及兩個用戶 user1 和 user2 在各自的工作區(qū)是如何工作并進行數(shù)據(jù)交換的危队，具體過程如下：

1. 在 E:\git_study\repos/ 中創(chuàng)建一個共享的版本庫 shared.git，以裸版本庫方式創(chuàng)建：

local1.png

2. 用戶 user1 克隆版本庫到上一級目錄的 user1/workspace 目錄中 ：

local2.png

這里通過本地協(xié)議 file:// 的方式來克隆钙畔，克隆一個剛初始化完成的裸版本庫會顯示警告茫陆，警告正在克隆的版本庫是一個空的版本庫。

注意：本地協(xié)議 file:// 后面的路徑為絕對路徑擎析，不能用相對路徑抓狭，否則會報錯偏化。

3. 設置 user.name 和 user.email 配置變量

配置的是版本庫級別的，所以不要加上 --global 或 --system 參數(shù)察郁，和全局設置區(qū)分開來癌佩，所有用戶共用全局配置氯葬，就無法模擬了吟孙。

local3.png

local4.png

4. 用戶 user1 創(chuàng)建初始數(shù)據(jù)并提交俐末，這里新建了文件 README 并輸入內(nèi)容 Hello. 。

local5.png

local6.png

5. 用戶 user1 將本地版本庫的提交推送到遠程版本庫：

local7.png

上述命令中使用了別名 origin 步责，其實際指向的就是 file:///e/git_study/repos/shared.git 這個遠程版本庫返顺，可通過配置文件查看：

local4.png

6. 用戶 user2 也克隆遠程版本庫并設置 name 和 email ：

local8.png

可以看到，用戶 user2 的本地版本庫和用戶 user1 有同樣的提交蔓肯。證明 user1 已成功推送到遠程， user2 也成功從遠程獲取到數(shù)據(jù)振乏。

現(xiàn)在蔗包，兩個用戶的工作區(qū)是相同的，如果兩人各自在本地版本庫中進行獨立的提交慧邮，然后再分別向遠程版本庫推送调限，會怎樣？是互相覆蓋還是提交失敗呢误澳？我們來模擬一下這個場景吧耻矮。

1. 用戶 user1 先在本地提交，然后推送到遠程版本庫：

創(chuàng)建對應目錄和文件 team/user1.txt 忆谓，在 user1.txt 中輸入文本裆装，進行提交和推送，如下圖：

local9.png

local10.png

可以看到倡缠，用戶 user1 成功推送到遠程版本庫哨免，也就是說遠程版本庫比用戶 user2 領(lǐng)先一個提交，如果 user2 仍基于舊數(shù)據(jù)而對本地進行改動昙沦，然后向遠程版本庫推送琢唾，會有什么結(jié)果呢？

2. 用戶 user2 創(chuàng)建對應目錄和文件 team/user2.txt 盾饮，在 user2.txt 中輸入文本采桃，進行提交：

local11.png

3. 用戶 user2 進行推送：

local12.png

推送失敗懒熙。一般情況下，推送只允許 “快進式” 推送普办，就是要推送的本地版本庫的提交是建立在遠程版本庫相應分支的現(xiàn)有提交基礎上的煌珊，即遠程版本庫相應分支的最新提交是本地版本庫最新提交的祖先提交。由于用戶 user1 推送了一個提交泌豆，所以用戶 user2 的推送是非快進式的定庵。

Git 是如何判斷此次推送是否快進式的呢？

判斷方式類似以下操作：用 git rev-list HEAD 命令顯示本地版本庫的最新提交及其歷史提交踪危，然后用 git ls-remote origin 命令顯示遠程版本庫的引用對應的哈希值蔬浙，最后判斷遠程的哈希值是否本地版本庫的祖先提交。

local13.png

由圖可知贞远，998627b 并不是祖先提交畴博，于是產(chǎn)生警告并終止了推送。

解決這個問題的方案有多個蓝仲，可以強制推送俱病，但是用戶 user1 的推送會被覆蓋，這種方式會形成競爭而不是協(xié)作袱结，是不合適的亮隙，就不介紹這種解決方式了。

非快進式強制推送如果被濫用垢夹，就會成為項目的災難溢吻，為了避免強制推送的問題，可以對版本庫進行配置來禁止用戶進行非快進式強制推送果元。將遠程版本庫的配置變量 receive.denyNonFastForwards 設置為 true 可以禁止任何用戶進行非快進式推送操作：

local18.png

總結(jié)：合理的工作協(xié)同要避免非快進式推送促王，向服務器推送時發(fā)現(xiàn)錯誤，不應該使用更改歷史的操作（變基而晒、修補提交）蝇狼，而是采用不會改變歷史提交的反轉(zhuǎn)提交等操作。由于他人先推送了新的提交導致遇到非快進式推送警告時倡怎，應該先執(zhí)行 git pull 獲取服務器端最新的提交并和本地提交進行合并迅耘，合并成功后再向服務器進行提交推送。

4. 執(zhí)行 git pull 诈胜，該命令會包含兩個動作：獲取遠程版本庫的提交(git fetch) 豹障，以及將獲取到的遠程版本庫提交與本地提交進行合并(git merge)。

local14.png

5. 合并之后焦匈，看看版本庫的提交關(guān)系圖：

local15.png

遠程服務器中的最新提交 998627b 成為了當前提交 a943da7 的父提交了血公，那么現(xiàn)在推送就是快進式的了，就不會有任何問題缓熟。

6. 執(zhí)行 git push 命令進行推送：

local16.png

7. 查看一下遠程版本庫的提交歷史：

local17.png

可以看到累魔，增加了用戶 user2 的提交并增加了一個合并的提交摔笤。