本文轉(zhuǎn)載自微信公眾號「 武培軒」，作者 武培軒 。轉(zhuǎn)載本文請聯(lián)系 武培軒公眾號。

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

[[331035]]

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

一起蓋房子吧

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

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

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

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

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

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

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

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

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

我想將設(shè)計保存在本地—git commit

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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