[導(dǎo)讀]大家好哇~歡迎來我的神奇的“科普”頻道！今天，我們?yōu)榇蠹医榻B程序員是如何怎么存檔并管理文件版本的。大家要做好心理準備，今天的“科普”稍有點點硬核，我想從需求分析，產(chǎn)品設(shè)計，代碼實現(xiàn)等全方位角度為大家“科普”，綜合的東西較多，可能不太好看懂......但內(nèi)容應(yīng)該還是有點點意思的，畢...
大家好哇~ 歡迎來我的神奇的“科普”頻道！
今天，我們?yōu)榇蠹医榻B程序員是如何怎么存檔并管理文件版本的。
大家要做好心理準備，今天的“科普”稍有點點硬核，我想從需求分析，產(chǎn)品設(shè)計，代碼實現(xiàn)等全方位角度為大家“科普”，綜合的東西較多，可能不太好看懂......
但內(nèi)容應(yīng)該還是有點點意思的，畢竟我總是寫一些亂七八糟的東西，如果暫時感覺難以消化可以考慮先收藏吖~
在開始之前，我們先為大家介紹一個概念，叫：版本管理。
我們先從日常生活講起。
阿菌這壞小子有時會想回到自己的過去，比如說回到小學(xué)時候的自己，回到初中時的自己，回到高中時的自己，或者回到大學(xué)前的自己，重讀一次大學(xué)等等......
人生的每個階段，我們都可以看成自己的一個版本，比如說小學(xué)版的阿菌，初中版的阿菌，高中版的阿菌，大學(xué)版的阿菌......
要是老天真的給我們每個階段都存了檔，那我們就可以回到過去的版本，重新開始了！
從舊版本發(fā)展出新的人生，或許我們的人生可以擁有好幾條分支路線呢......
雖然目前看來不太現(xiàn)實，就算真的有得選，阿菌也絕不會回到過去的版本，因為阿菌不敢保證在另一條人生分支上，還能遇到波姐......
咳咳，打?。?/span>
雖然人生沒有存檔，但是電腦上的文件可以存檔！
大家考慮以下場景：假設(shè)學(xué)院安排我們做一次畢業(yè)晚會宣傳活動，既要有 PPT，又要有文稿，還得有海報。
于是我們高高興興地把全學(xué)院的本科生資料編寫到了 PTT，文稿和海報里。
這個時候，學(xué)院說：怎么可以只有本科生的資料？研究生的相關(guān)資料也要加進去！
然后我們在現(xiàn)有的 PPT，文稿和海報里，加入了研究生的資料。
接著學(xué)院說：臨時通知，研究生的晚會另外舉行！
大家可能就傻眼了：我們已經(jīng)在 PPT，文稿和海報里加了研究生的信息，而且已經(jīng)和本科生的內(nèi)容融合到了一起，這刪起來也太麻煩了吧?。。?/span>
要是我們提前把本科生的策劃資料保存為一個版本就好了，這樣就能直接把本科生的版本交給學(xué)院，完成工作。
現(xiàn)在場景有了，痛點有了，接下來我們著手設(shè)計一款軟件產(chǎn)品來解決這個問題（有同學(xué)會說，阿菌你扯淡，我每個版本復(fù)制一份就行啦，搞個軟件出來干嘛？呃呃，堅持看完就懂啦，它不只存檔這么簡單哦。我們手動拷貝存檔容易出現(xiàn)各種各樣的問題，比如忘了存，忘了存在哪，存的順序搞亂了等等......試過就會有體會哦）。
現(xiàn)在我們有一個文件夾，文件夾目錄下有 PPT，文稿和海報，要不我們就在這里創(chuàng)建多一個文件夾用于存檔吧！把名字起名為“.jun”就好啦！
現(xiàn)在我們創(chuàng)建好了一個“.jun”文件夾用于存放當(dāng)前目錄的版本信息，接下來我們要思考的是，該如何保存各個文件的版本？
在計算機領(lǐng)域，我們來到的環(huán)節(jié)應(yīng)該叫設(shè)計底層數(shù)據(jù)結(jié)構(gòu)，我們可以把“.jun”文件夾看成一個數(shù)據(jù)庫，這個數(shù)據(jù)庫會用來保存當(dāng)前文件夾下文件的版本數(shù)據(jù)。
嗯，不如這樣吧！
我們就把這些.doc、.psd、.ppt文件稱為 object 吧?。ǚ凑膊恢澜惺裁春茫┪覀冊凇?jun”文件夾下創(chuàng)建一個“objects”文件用于存放各個 object 的信息，這樣，我們就有了一個 object 數(shù)據(jù)庫了！
呃，聽起來好像很厲害，其實阿菌只是創(chuàng)建了兩個文件夾......
現(xiàn)在我們想想一個 object 該存些什么東西比較好，究竟什么東西才能精準定位一個文件的版本信息呢？
想來想去，不如這樣吧，我們一個 object 至少得包含三個信息：
1. ?文件的原本信息，我們PPT，WORD文檔中的內(nèi)容就叫原本信息，直接保存原本信息可能需要很大的空間（至少和這些文件本身一樣大），我們可以先壓縮，再保存。
2. object 的類型，考慮到我們當(dāng)前文件夾下除了有 PPT，文稿和海報之外，以后還可能放新的文件或者新的文件夾，文件和文件夾都應(yīng)該叫 object，只不過可以用不同的類型區(qū)分他們。（大家可以在這留個心眼，這是這款版本控制管理軟件的精華部分，后面就知道啦）
3. 一串字符數(shù)字，我們起個專業(yè)點的名字叫哈希值，用于標識當(dāng)前的 object，每個 object 都有獨一無二的哈希值（其實就一串亂七八糟的數(shù)字字符，這樣不容易重復(fù)）。
看到這里，大家可能會有疑惑：你們?yōu)樯兑恢痹谡f怎么設(shè)計，我們更想知道的是，為什么這么設(shè)計？
下面揭示謎底：
大家先看第一張圖，當(dāng)前文件夾下的 PPT，文稿和海報，我們可以分別用三個 object 表示：
由于他們放在同一個目錄下，于是我們可以用一個大的 object 來標記他們，我們把這個大 object 的類型定義為 tree（樹干的感覺），這個 tree object 對等的就不是一個個文件了，而是一個文件夾：
細心的讀者朋友會發(fā)現(xiàn)：咦？這個 tree object 貌似已經(jīng)包含了當(dāng)前文件夾下的所有文件信息，也就是說，這個 tree object 貌似已經(jīng)可以記錄當(dāng)前文件夾的版本信息了！
我們可以通過這個 tree object 找到PPT，文稿和海報對應(yīng)的 object 們，這些 object 保存有PPT，文稿和海報某個時間點的原信息，我們只要把這些信息解壓出來，就能把文件夾恢復(fù)到曾經(jīng)存檔時候的樣子了。
接下來的問題是：我們不會只保留一份存檔，我們會保存很多份存檔，如何才能把一系列存檔組織起來呢？
接下來我們引入一個新的 object 類型，我們叫起名叫 commit 類型好了，就是一個提交的意思。想要把存檔串聯(lián)起來，我們得加上一項參數(shù)，指明上一個 commit object 是誰，或許我們還可以加上時間等信息，這樣一來，每一次提交就是一個版本：
上面這個圖由于位置不夠，畫得不夠直觀，我們再畫一個圖，大家明白每個 commit object 都指向一個 tree object 就行了。也就是說：commit object 只是 tree object 的一層封裝，雖然還原出一個文件夾過去的存檔我們只需要 tree object，但封裝成了 commit object 后，通過“father”這個屬性，就能把一系列的存檔連起來，而且還能蓋上時間戳，這樣整個存檔記錄就很清晰了。
講到這里不知道大家會不會冒出一些奇怪的想法，假設(shè)學(xué)院布下了兩個任務(wù)：我們本科生，既要和研究生搞一次畢業(yè)聯(lián)誼，又要和博士生搞一次畢業(yè)聯(lián)誼，我們這套版本管理系統(tǒng)還能用上嗎？（也只有阿菌才能想出這樣奇奇怪怪的活動）
當(dāng)然可以啦，請看下圖：
我們可以創(chuàng)建兩個 commit object（兩個新的存檔），分別指向最開始保存了本科生資料的存檔，然后我們就能分別在兩個新的存檔上干活啦，而且兩個存檔互不影響，可以繼續(xù)在兩個存檔之后建立新的存檔，就像下面這樣：
我們可以給上面的功能起個好聽的名字，叫“分支”。
分支的功能還可以這樣用，我們考慮下面這種場景：
學(xué)院不再搞花樣了，只要做好本科生的畢業(yè)活動策劃就行。但是學(xué)院規(guī)定的時間很短，阿菌一個人做不完，他找來了他的同學(xué)阿叉和阿勾一起做，三個人分別負責(zé)PPT，文稿和海報。
為了不影響最開始的版本，他們?nèi)齻€每人拉出來一條分支進行工作，每個工作階段的內(nèi)容照樣進行版本管理：
等各自的工作完成后，合并出最新的版本：
這樣一來，大家協(xié)同工作起來就方便多啦。
可能有同學(xué)會問：阿菌，你設(shè)計的 commit object 不是有一個父指針么？每個父指針指向上一個 commit object，在上面的圖里，最終版的父指針指向誰呀？貌似一共有三個父節(jié)點？
呃，這個確實是阿菌疏忽了，圖沒有畫好......
是這樣的，有時候我們數(shù)據(jù)結(jié)構(gòu)設(shè)計好了，最好就不要改了，遇到現(xiàn)有數(shù)據(jù)結(jié)構(gòu)不能掌控的場景，我們就要設(shè)計處理流程，這就是所謂的“算法”吧......（畢竟增刪改查某種程度也算是算法......）
我們總是說：軟件 = 數(shù)據(jù)結(jié)構(gòu) 算法，下面阿菌帶大家還原這個處理流程的設(shè)計。
因為我們的 commit object 只能指向一個父節(jié)點，于是我們設(shè)計的合并流程是這樣子的：最終的合并，交給一個人處理（站在一條分支上處理，假設(shè)叫它主分支）。
從上圖可以看到，我們以阿叉制作PPT的分支作為主分支，把阿勾的分支內(nèi)容合并到了阿叉的分支上，這樣阿叉的分支就多出來一個合并節(jié)點，這個合并節(jié)點指向的是阿叉分支上的前一個節(jié)點，這樣一來，PPT 和文稿內(nèi)容就合并到主分支上了。
滴滴滴~ 下面我們把阿菌那壞小子制作的海報也合并上去：
這樣一來，我們既沒有破壞原來的數(shù)據(jù)結(jié)構(gòu)，也沒有破壞軟件的設(shè)計：一個存檔版本管理軟件，我們可以在阿叉這條主分支上找到所有的內(nèi)容。
當(dāng)然阿菌這樣的設(shè)計不太好，我們其實可以設(shè)計得更好，比如說單獨抽出來一條主分支，阿叉，阿勾，阿菌制作各自內(nèi)容的時候單獨拉分支（一共四條分支），每個人都制作好了，再合并回主分支。這樣主分支就會非常干凈利落，而不是像現(xiàn)在這樣，在主分支上，還能看到阿叉的各個版本......
呃呃，軟件開發(fā)就是這樣的啦，在摸索中不斷總結(jié)最佳實踐！
估計大家看著看著就能看出來啦：阿菌，你這講的不是 Git 么？
沒錯，阿菌今天介紹的就是一款叫 Git 的分布式版本控制軟件-版本控制部分的底層設(shè)計原理，現(xiàn)在大多數(shù)程序員都是基于 Git 進行協(xié)同開發(fā)的。和上面例子不同的是，程序員寫的是代碼文件，而不是文稿和PPT。有時候一個功能往往會有好幾個程序員開發(fā)，大家可以理解為分組開發(fā)。常見主流的協(xié)作流程會是這樣的：
簡單介紹一下：
一、master 分支存儲了正式發(fā)布的歷史版本，是一個功能完整且隨時可以發(fā)布到線上進行部署的可用分支。
二、Hotfix 分支是用來修復(fù)線上bug，快速打補丁的。
三、Release 是一個發(fā)布分支。
四、Develop 一般作為功能的集成分支。
五、 Feature 分支則是功能分支。
至于每個分支具體的用法，大家可以到網(wǎng)上搜索，根據(jù)阿菌的經(jīng)驗，其實看了也沒啥用。只有真正到公司里參與到開發(fā)項目中，才能真正領(lǐng)會到各個分支的意義。
今天介紹的內(nèi)容，是 Git 這款軟件最基本的原理，在搞清楚了這個的基礎(chǔ)上使用 Git，會輕松很多。Git 的另一個重要的特色是：分布式。也就是說，它是用于多人（公司或團隊）協(xié)同進行存檔和版本控制的。
有位大神看了我們的文章后認為如果我們能講講分布式，那這篇文章會更加加分，那肯定沒問題。
我們現(xiàn)代的程序員，寫代碼的時候上來就是用 Git，理所應(yīng)當(dāng)以為版本管理系統(tǒng)都是現(xiàn)在分布式的樣子。殊不知，以前的版本管理系統(tǒng)都是集中式的。
我們先簡單介紹一下什么叫集中式，還是用本文的案例：
像上圖這樣，有一個集中的地方管理所有文件，每個人開發(fā)只要拉取特定文件進行開發(fā)，這叫集中式開發(fā)。
集中式開發(fā)的弊端大致有以下兩點：
- 效率。中央倉庫出了問題，所有人都無法正常工作了，因為大家都依賴他拉取和推送文件。
- 穩(wěn)定性。中央倉庫掛了，存檔就沒了。
針對以上弊端，我們能想到的，最直接的處理方式是：每個人都保存一份倉庫的拷貝。如下圖所示：
有同學(xué)會問，欸，阿菌，那我還有必要學(xué) SVN 那些集中式版本管理軟件么？
當(dāng)然不用，Git 的出現(xiàn)，已經(jīng)完全顛覆了過去的集中式版本管理系統(tǒng)。SVN 的版本管理策略和 Git 還是有很大區(qū)別的，阿菌沒有說 SVN 不好，大家要知道，這里涉及的原因很多。這是時代變化所引起的變革，以及大環(huán)境所需導(dǎo)致的變遷，不存在孰好孰壞的問題。
我們嘗試開辟一個角度想（不一定對）：在以前的年代，內(nèi)存，磁盤，計算資源都是很寶貴的，當(dāng)時的機器根本就不適宜支持我們在每臺機器上，保存完整的工程文件存檔，也不可能采用 Git 這種壓縮保存整個文件原信息的策略（增量保存能省很多空間，代價是犧牲性能）。所以，使用 SVN 這樣集中式的版本管理系統(tǒng)，或許是個很好的選擇。
現(xiàn)在機器越來越好了，磁盤大，網(wǎng)絡(luò)快，直接就能在每個人的機器上保存完整副本。更重要的是，Git 本身的設(shè)計非常優(yōu)良，它站在 Linux 操作系統(tǒng)肩上發(fā)家（最初是因為想分布式開發(fā) Linux 而創(chuàng)造的 Git），后來還發(fā)展出了 Github 這樣的開源社區(qū)。慢慢地，大家都愿意遷移到 Git 上開發(fā)了。
再換一個角度：大家想想，如果一個工程真的非常非常龐大，單臺機器不能拉取整個工程進行開發(fā)，集中式的版本控制無疑是更好的選擇。
但是現(xiàn)在業(yè)界流行微服務(wù)，系統(tǒng)的拆分解耦是大勢所趨，這也注定了大工程會被拆分成小工程。而體量小的工程，恰好非常適合使用分布式版本控制。
存在即合理，任何一項技術(shù)，我們在評價它時，都不能脫離時代背景和現(xiàn)實需求。
我們這篇文章不教操作，關(guān)于 Git 操作的文章，網(wǎng)上一抓一大把，各種奇技淫巧，應(yīng)有盡有。
各位如果想自己玩出奇技淫巧，那就跟著阿菌一起深入數(shù)據(jù)結(jié)構(gòu)探索原理吧，那些只教奇技淫巧的博客，通常都不怎么說原理，懂了原理才能更好地發(fā)掘奇技淫巧吖！
有同學(xué)可能會問：阿菌，原理懂了，但是不太能和操作對應(yīng)起來，我們平時用 Git，就是一條 pull 和一條 push，兩條指令走天下。分支我是懂了，但這些分布式操作我還不太懂，不太能聯(lián)系起來。。。
阿菌實習(xí)時的導(dǎo)師，曾教給阿菌一個非常重要的學(xué)習(xí)方法：當(dāng)我們看到一個沒接觸過的東西的時候，我們首先要想 ——?如果這個東西交給你來做，你會怎么實現(xiàn)？
阿菌看過一點點 Git 的源碼，也翻過官方文檔，但是不可能在這里把這些東西全倒出來，我們嘗試引導(dǎo)大家一點點思考。（最終的深入精確學(xué)習(xí)，還是建議大家看源碼文檔，想要深入學(xué)一個東西，這苦是不得不吃的）
我們沿用這個圖進行講解，在看之前，大家務(wù)必先搞清楚 object 的底層數(shù)據(jù)結(jié)構(gòu)，以及怎樣把 object 串聯(lián)起來形成分支。我們先回顧一下當(dāng)時的總覽圖：
之前我們提到以阿叉作為主分支，是一個不太好的設(shè)計，但是不影響我們講解，我們假設(shè)阿叉已經(jīng)開發(fā)完了，遠程倉庫就是阿叉的倉庫。
現(xiàn)在阿勾已經(jīng)開發(fā)完了，阿勾會把他的本地倉庫推送到遠程倉庫，阿勾的倉庫是這樣子的：
阿菌能猜到一些小伙伴看到這懵逼了，千萬不能懵逼，一定要全文串聯(lián)回憶，我們的版本管理軟件，就是一條鏈表加樹，這里的每個圈圈都是一個 commit object，他們是對應(yīng)的，阿菌只是用一個小圈圈代替，以節(jié)省位置：
明白了這個之后，我們來看一下合并的流程，首先阿勾會把自己的本地倉庫推送到遠程倉庫（主分支）：
現(xiàn)在，大家明白，為什么合并分支會多出來一個提交了吧？
還有一些常用的指令，什么 rebase 吖，不就是調(diào)整鏈表么？不懂的話可以去刷刷算法題，打打基礎(chǔ)。
不過，多人一起辦公難免會遇到一些問題，比如說大家同時修改了一個文件，發(fā)生了沖突。但懂了原理后這都很好解決，大家溝通一下用誰修改的版本就好了，協(xié)商出一個不沖突的版本，然后合并就行。合并的原理上文已經(jīng)提到啦，一通百通。
也正由于是多人協(xié)同辦公，注定我們的軟件要具備聯(lián)網(wǎng)的能力，涉及許多網(wǎng)絡(luò)交互，這是分布式軟件必不可少滴內(nèi)容。但大家要相信，最底層原理懂了，具體如何使用，如何與他人在網(wǎng)絡(luò)中合作，那都是很簡單的內(nèi)容，學(xué)一個軟件關(guān)鍵是要學(xué)透它的底層數(shù)據(jù)結(jié)構(gòu)，學(xué)明白后，上層操作都會引刃而解的。
下載文檔
