在下面的幾個案例裡面，為了使講述的內容更簡潔，我們將不會按照上面的規範去寫很規範的提交註釋，並使用-m選項去做git commit。聽我們說，但是不要學我們做^^。

衝突發生在不同檔案

你遇到的最簡單的私有專案的配置可能是隻有兩三個開發者。這裡的“私有專案”是指閉源不會對外公佈的專案，但是你和其他開發者都可以訪問程式碼庫。
在這個背景下， 你可以像使用Subversion或其他程式碼管控系統一樣去跟蹤一個專案流程。你仍然可以使用比如離線上傳、分支、合併等功能，並且流程是非常相似的。主要的不同是合併操作可以只需要有客戶端，而不必立即同步到服務段。讓我們來看一下，當兩個開發者開始共同開發這個程式碼庫會是什麼樣子。John是其中一位開發者，克隆了這個程式碼庫，做了一些修改後，然後把修改上傳到了本地。（在這個案例裡面，我們將以…代替出現的大段出現的協議資訊，以簡化案例）

# John's Machine
$ git clone [email protected]:simplegit.git
Initialized empty Git repository in /home/john/simplegit/.git/
...
$ cd simplegit/
$ vim lib/simplegit.rb
$ git commit -am 'removed invalid default value'
[master 738ee87] removed invalid default value
 1 files changed, 1 insertions(+), 1 deletions(-)
 

另外一位開發者，Jessica，做了同樣的事情， 克隆了工程並提交了自己的修改到本地：

# Jessica's Machine
$ git clone [email protected]:simplegit.git
Initialized empty Git repository in /home/jessica/simplegit/.git/
...
$ cd simplegit/
$ vim TODO
$ git commit -am 'add reset task'
[master fbff5bc] add reset task
 1 files changed, 1 insertions(+), 0
 
 deletions(-)

現在Jessica同步她的修改到伺服器上：

# Jessica's Machine
$ git push origin master
...
To [email protected]:simplegit.git
   1edee6b..fbff5bc  master -> master

John也打算同步他的修改到伺服器：

# John's Machine
$ git push origin master
To [email protected]:simplegit.git
 ! [rejected]        master -> master (non-fast forward)
error: failed to push some refs to '[email protected]:simplegit.git'

John沒能成功同步他的修改到伺服器，因為Jessica也在同時做了一樣的事情。這一點對曾用過Subversion的你特別重要，因為你可能注意到了兩個開發者的修改沒有涉及相同的檔案。在這種情況下，Subversion會自動完成這個合併，但是Git卻不會，所以你需要先在本地merge兩個人的修改。John不得不先獲取Jessica的修改，將這些修改合併再和伺服器同步。

$ git fetch origin
...
From [email protected]:simplegit
 + 049d078...fbff5bc master     -> origin/master

這時，John的本地倉庫差不多是這樣的：

John’s divergent history

John知道Jessica的修改與自己的並不相關，但是他還是不得不先把這些修改合併到他本地的庫中，這樣才會被伺服器允許同步他的修改：

$ git merge origin/master
Merge made by recursive.
 TODO |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

合併動作完成了，John的上傳記錄現在是這個樣子的：

John’s repository after merging origin/master.

現在John可以測試他的程式碼以保證它們仍然正常有效，並且他可以同步自己的修改到伺服器了:

$ git push origin master
...
To [email protected]:simplegit.git
   fbff5bc..72bbc59  master -> master

最終，John的提交記錄是這個樣子的:

John’s history after pushing to the origin server.

衝突發生涉及同一檔案

與此同時，Jessica還在開發一個主題分支。她建立了一個名為issue54的分支，然後在這個分支上提交了三次修改。她還沒有獲取John的修改，現在他的提交記錄是這樣的：

Jessica’s topic branch.

Jessica要同步John的修改：

# Jessica's Machine
$ git fetch origin
...
From [email protected]:simplegit
   fbff5bc..72bbc59  master     -> origin/master

Jessica拉取了John同步到伺服器上的修改，現在Jessica的提交記錄是這樣的：

Jessica’s history after fetching John’s changes.

Jessica認為她的分支已經準備好了，但是她想知道她必須merge哪些東西后她才可以向伺服器同步她的修改。她執行git log 去檢視以下內容：

 $ git log --no-merges issue54..origin/master
commit 738ee872852dfaa9d6634e0dea7a324040193016
Author: John Smith <[email protected]>
Date:   Fri May 29 16:01:27 2009 -0700

   removed invalid default value

“issue54..origin/master”這個引數的語法是一個日誌過濾器，可以要求Git只顯示在第二個引數分支origin/master上有，但是issue54分支上還沒有的commits的列表。更多這個引數語法請參看”Commits Ranges”。
現在，我們從輸出看到Jessica未整合的John的提交只有一個。如果Jessica要整合origin/master，這個commit將會修改她在本地的內容。現在Jessica要先合併她的主題分支到主分支中，再合併John的那個commit到她的主分支，最後同步到伺服器。 首先，Jessica回到她的主分支去整合所有這些修改：

$ git checkout master
Switched to branch 'master'
Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded.

Jessica可以先合併 origin/master，也可以先合併issue54分支，它們都是需要上傳的，所以順序並不重要。最後的專案狀態snapshot都應該是一樣的， 不管採用什麼順序，只有上傳記錄會有一點不同而已。Jessica選擇先合併issue54分支：

$ git merge issue54
Updating fbff5bc..4af4298
Fast forward
 README           |    1 +
 lib/simplegit.rb |    6 +++++-
 2 files changed, 6 insertions(+), 1 deletions(-)

合併成功。就像你看到的這是一個非常簡單快推進， 現在Jessica要開始合入John的修改了（即origin/master主幹分支的內容）：

$ git merge origin/master
Auto-merging lib/simplegit.rb
Merge made by recursive.
 lib/simplegit.rb |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

所有的東西都很乾淨的合併了，現在Jessica檢視到的上傳記錄像是這樣：

Jessica’s history after merging John’s changes

Jessica的master分支是可以訪問origin/master的，所以她能夠成功的同步修改到伺服器(假設John在這段時間沒有上傳過其他修改)：

$ git push origin master
...
To [email protected]:simplegit.git
   72bbc59..8059c15  master -> master

每一個開發者都提交自己的修改並且也成功合併過別人的修改。

Jessica’s history after pushing all changes back to the server

這是一個最簡單的工作流程例項。你在開發一段時間後，通常是指在一個主題分支開發中，要整合這段時間完成的修改到你的master分支以便提交。當你打算分享?你的修改，你把修改合入你的master分支，獲取origin/master並且合入，最後同步到伺服器。這流程順序類似下面這個圖：

General sequence of events for a simple multiple-developer Git workflow.

內容有點多，翻譯不夠細緻，後續持續改進。

原文連結