一個故事帶你瞭解版本控制

當咱們初次在項目中使用版本控制時，這個概念可能難以理解。我看到不少人（也包括我）都在運行諸如 git pull，git push 以及運行其餘一些我不理解的命令。爲何我既要 commit 還要 push？爲何每一個新特性都須要新建一個分支？

在使用 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 可以複製代碼並在不一樣版本上獨立工做，這使它成爲構建應用程序的任何人(甚至是單獨工做的開發人員)的一個很好的選擇，它使您有機會保留代碼的多個版本，並跟蹤每一個更改的全部特徵，好比誰作了更改以及什麼時候作的更改。

感謝你們的閱讀，歡迎留言進行交流討論。

最好的關係就是互相成就，你們的在看、轉發、留言三連就是我創做的最大動力。

參考

https://towardsdatascience.com/a-simple-story-to-explain-version-control-to-anyone-5ab4197cebbc