把一個場景推到極端是不好的論證方法。

首先，提交的目的是什麼，如果只是為了同步程式碼給別人，那git真沒什麼亮點，甚至離線提交還會讓人誤解，算是個缺點。

我個人認為提交的目的，一是暫存程式碼（版本管理，方便後續回滾神馬的），二是作為代碼的階段性節點（這個功能做完了，提交一下），三才是向伺服器同步，與他人分享。

Git的離線提交可以很好地完成以上目的一二兩點。而且因為是離線提交的，你可以在與伺服器同步之前很方便地修改提交記錄，這有什麼用呢？例如我寫了一個方法，它可以工作，但是我想重構一下，又不確定重構後能否正常工作，於是先提交一個版本，萬一重構壞了還可以回滾回來。等我重構完了之後，再提交一次。此時就有了同一功能的兩次提交，而你可能只希望別人看到一個提交“XX功能完成”，於是你可以很方便地將這兩次提交合併起來。最後合併之後，程式碼版本庫是非常乾淨的，所有的提交記錄都是因為真的要提交而提交，這些提交是可以直接寫入release note的，而不會出現“測試XXX”，“嘗試XXX”之類的提交。基於同樣的結果，你還可以將一次寫的程式碼分多次提交，例如我寫了三個功能，我可以選擇提交三次，最後再同步到伺服器，而在SVN中，你（在沒網時寫的程式碼）只能一次提交上去，然後寫“完成了A，B，C三個功能”，這樣其實不便於別人查看你的程式碼，也不利於對A，B，C分別進行回滾。

所以git的離線提交帶來的是彈性。並不是說有了離線提交，我就可以不需要伺服器，空氣會自動幫我完成協同工作。這是我開頭說的「把一個場景推到極端是不好的論證方法」的意思。 git相比svn，協同的方式會多一些，也靈活一些，但並不能避開協同的問題，你仍然需要協同和合併代碼。

在合併程式碼的過程中，和SVN一樣，也會遇到衝突的情況，所以條件允許的情況下及時與伺服器同步程式碼仍然是個好習慣。但是，由於git是基於內容追蹤版本，svn是基本檔案追蹤版本，導致git的合併比svn可靠得多，也就是同樣情況下，git碰到衝突的可能性比svn小很多。

最後，由於git的離線提交特性，再加上git的分支特別好用，還可以實現本地多分支管理功能，也就是你在做一個功能時可以在本地開一個分支，然後在本地提交，做完了再合併進去推到伺服器，對其他人而言，這個分支是不存在的，但是對自己而言，卻可以隨時切換工作狀態（寫新功能還是切回去改bug）。 svn也可以切分支，但它的分支是無法只存在本地的，如果採用分支協作的方式，會導致分支非常多，而有一些根本是其它人不需要關心的。而更麻煩的是，如果你新功能寫到一半，要切回去改bug，此時只能將未完成的程式碼提交到svn伺服器，我個人認為（將未完成的程式碼提交到版本庫伺服器）是一種非常不好的行為，而用git，因為分支是離線的，我提交完，切回去改bug，再切回來就是，等功能做完後合併一下提交記錄就一切圓滿了。

如果雙方改的是不同的文件，或是同一個文件的不同部分，那麼 git 是可以自動合併的。

如果修改的是同一個檔案同一個部分，git 就沒辦法自動合併了，這種情況被稱為「衝突」，git 會列出雙方的最新版本，然後由進行合併的人(例子裡是C ), 手動進行編輯。

在實際開發中，如果兩個人只是往這個文件裡加函數，是完全可以自動合併的，衝突主要是出現了修改了同一行的情況。

對補充的回答：

很多介紹強調 git 可以離線 commit, 意在於和 svn 做對比。 svn 中，只有伺服器上有完整的版本庫，客戶端的程式碼歷史並不是完整的。而 git 中每一個客戶端都是一個完整的版本庫，push 和 pull 操作其實是在多個完整的版本庫之間做同步。

這樣的優勢就是不怕伺服器掛掉或遺失，每個人都有完整的版本庫，這也是Linus 開發git 的出發點(Linux 是一個多人分散式協作的開源專案). 而劣勢就在於權限管理比較差，每個人都有完整的版本庫有可能會導致程式碼(歷史上所有的修改)不小心洩漏。

終於遇到一個可以好好回答的問題了；

先說一下題主的假設：

C 從第 6 天開始不跟遠端互動了，自己玩了，這是做什麼？這不是分散式，分散式是在網路可用下說的，分散式不是隔著幾天不跟遠端同步；

既然檔案叫GlobalFunction.php，那么这个文件就是修改极少的（或者说修改相同的一行是很少的），类似于Python下的setup.py，有时只是到了新版本发布的时候你才会修改一下version變數吧；

GIT 的分支概念個人理解是可以更快速的基於某個或某些分支進行協作開發，例如一個倉庫foo有一个 分支叫做：master，那么 A，B，C 进行协同开发的时候会在本地基于这个共同的分支master进行本地分支，比如 A 的本地分支叫a-dev，B 的叫：b-dev，C 的叫c-dev，怎麼來的呢？

git checkout -b xxx origin/master # xxx 代表 `a-dev` 等

其次說一下題主說的合併：

如果 C 在本地基於master进行了本地分支c-dev那么 C 一直可以更新本地 master 分支而不影响本地分支c-dev（而此时你可以一直在c-dev分支）：

git pull origin master:master

那麼把本地master更新了，怎么反应在c-dev呢？ 很簡單，GIT 已經想好了：

git rebase master # 此时你在 `c-dev` 分支

經過了上面，可能會發生的情況無非是兩種：1. 出現合併衝突，rebase失败；2. 无冲突（可能会自动merge），本地master最新状况跟本地c-dev合併；

對於1 的出現，GIT 不會自動搞定衝突，卻可以嘗試自動合併（merge），失敗了，叫出現了衝突；出現了衝突一般是指不同的提交，修改了同一文件的同一行（幾行）內容，需要開發者自己搞定衝突；

個人總結

分支是 GIT 區別於其他集中式版本控制系統的殺手鐧（killer feature）；rebase是 GIT 分支的殺手鐧；GIT 的分散特性離不開 GIT 良好的分支特性；

在發生衝突的時候SVN是逐行比較，而Git是記錄的操作，例如增加一行、刪除一行或修改一行，因而合併的過程更容易

你說的問題只能透過分支來解決

簡單地說，可能可以自動合併，也可能不行。
Git的每一個commit保存的是diff，樓主可以隨便git show一個commit看一下。 diff會在原始修改行的前後若干行裡去嘗試匹配，如果能匹配上，那麼這個diff就可以自動合併。
舉個例子，如果C的patch修改了第五行的一個值，他沒有提交。 A和B一直在GlobalFunction.php裡添加新的功能，這些功能都在檔案的尾部添加，那麼C在合併的時候，Git可以透過cherry-pick的方式完成合併。
如果雙方都修改了同樣的地方，那就得手動解決衝突了。