當我們初次在專案中使用版本控制時，這個概念可能難以理解，我看到很多人（也包括我）都在運行諸如 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
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/985.html
標籤：其他
下一篇：產品經理的首要技能