本文轉載自微信公眾號「 武培軒」，作者 武培軒 。轉載本文請聯系 武培軒公眾號。

當我們初次在項目中使用版本控制時，這個概念可能難以理解。我看到很多人(也包括我)都在運行諸如 git pull，git push 以及運行其他一些我不理解的命令。為什么我既要 commit 還要 push?為什么每個新特性都需要新建一個分支?

[[331035]]

在使用 Git 進行協同工作幾個月后，對于版本控制這個概念就比較清晰了，可以更好地理解和使用版本控制來進行協作。下面通過一個小故事來說明版本控制的工作方式及其在項目中的優勢吧!

一起蓋房子吧

在這個美好的合作項目中，我們將嘗試一起蓋房子。簡單點說，我們只有兩個人在這棟房子里工作。我們不是房子的主人，我們為別人(利益相關者)處理房子的內容，他告訴我們他想要什么，想要在哪里。

我們有 4 面墻—主(Master)分支

我們從 4 面墻和屋頂開始，這是堅固的，耐久且非常好的，這四堵墻代表我們的 Master 分支，它們目前已經實施，并且不會被刪除。利益相關者批準了這四堵墻，他甚至可能親自選擇了它們，并且希望保留它們。我們需要做的就是改善這四堵墻，在上面或周圍建造。無論如何，我們要建造的任何東西都將以這四堵墻為基礎。

業主想要一間客廳和一間廚房-特性(Feature)分支

正如我之前提到的，有兩個人在做這個項目，我和另外一個同事張三。每個房間都是一個特性，在這種情況下，為了使結果最大化，我和張三將研究不同的特性，我將設計客廳，張三將設計廚房，到目前為止一切都很順利。

我們都創建了一個特性分支，我們還知道必須使用約定來命名我們的分支，因此，我們將以正在處理的工作(在本例中，是一個新特性)、該特性的名稱和我們的名字。

• feature-living_room-wupx
• feature-kitchen-zhangs

命名分支有多種約定，這只是其中一個建議。

我們都從主分支創建特性分支，所以我們一開始都有相同的四面墻，然而，我們的特性分支完全是主分支的獨立副本，對主分支的內容沒有直接影響，這就保證了如果我和張三完全破壞了四面墻其中的一個，主分支的四面墻仍然是站立的。

我想將設計保存在本地—git commit

提交就像將更改保存在本地，每一次新的提交都有一個數字，也代表了你可以返回的保存點，就像在任務游戲中你可以返回到之前的保存點一樣，所以當張三建造櫥柜的時候，他可以提交它們以保證他的更改不會丟失，并且如果他建造的下一個部分危及到櫥柜的質量，他還可以回滾回去。因此，當Bob建造廚柜時，他可以提交它們，以免丟失更改，并承諾如果他制造的下一部分會危害廚柜的質量。

每次提交還需要一條消息，因為寫一些關于你的提交的內容以便讓每個人都知道這個“保存點”包括什么是一個很好的實踐，張三提交的消息寫道“創建紅色廚房櫥柜”。

我想將設計保存在存儲庫中的安全位置—git push

存儲庫是存儲所有分支的地方，包括主分支，它就像一個文件夾，里面有關于項目的所有文件，包括它們的修訂歷史。

Git push 獲取你的所有提交并將它們發送到分支的遠程版本，該版本可以在在線存儲庫中獲得，所有參與其中的的開發人員都可以看到對分支所做的更改。因此，張三將他的提交推到他的遠程分支，我現在可以看到張三關于紅色櫥柜的提交。

我的客廳裝修好了，現在怎么辦呢?-開發分支和合并(merge)請求

我們的開發分支是一個集成我們的房間(或功能)的地方，在這里，我們嘗試把我們的設計(或功能)結合在一起，看看我們的客廳和廚房的功能是否很好地結合在一起。

如果我想把我的客廳添加到開發分支，我必須做一個合并請求(pull request)，通常，在遠程分支上發生合并之前，至少必須有一個其他開發人員批準你的合并請求。

張三的廚房做完了，我們的設計不匹配—合并沖突(Merge conflicts)

我試圖將張三的新變更合并到我的分支中，但是如果我沒有把張三的開放式廚房一側的墻砌好，會發生什么呢?我們的設計存在沖突，Git 可以自動解決一些沖突，但不能解決所有沖突，Git 有時需要你的幫助來確定應該保留哪些更改，因為其中一些更改是相互沖突的。換句話說，它需要知道保留誰的“設計”(或代碼)是正確的選擇。

假設我是犯錯的人，我可以告訴 Git 在設計廚房墻壁時保留Bob的部分，而不是我的。

我們什么時候可以把廚房和客廳加到主分支?

項目的這一部分通常包括測試、批準，一旦我們的設計經過了全面的測試，這意味著它們也能很好地一起工作，并且我們的利益相關者，房屋所有者批準了這些設計，我們就可以決定將我們的更改合并到主分支，這意味著從現在開始，我們房子的穩定版也將包括我們的客廳和廚房，因此所有的新分支至少應該包括這些房間。

在某些情況下，明智的方法可能是將主分支以前的每個版本都保存在不同的分支中，然而，處理主分支的正確方法取決于你的團隊和公司的需求或準則。

總之，版本控制是簡單和安全協作的核心

在團隊項目中使用 Git 允許多個開發人員獨立地處理同一個項目，而不會經常干擾彼此的輸入。每個開發人員都可以獲得一個獨立的代碼版本，他們可以修改這個版本，而不必承擔破壞穩定版本代碼的風險。

Git 能夠復制代碼并在不同版本上獨立工作，這使它成為構建應用程序的任何人(甚至是單獨工作的開發人員)的一個很好的選擇，它使您有機會保留代碼的多個版本，并跟蹤每個更改的所有特征，比如誰做了更改以及何時做的更改。