>[success] # 版本控制系統 版本控制也是一種軟件工程技巧，借此能在軟件開發的過程中，**確保由不同人所編輯的同一程序文件都得到同步**，版本控制在軟件開發中，可以幫助程序員進行代碼的**追蹤、維護、控制**等等一系列的操作 * **不同版本的存儲管理** * **重大版本的備份維護** * **恢復之前的項目版本** * **多人開發的代碼合并** * **記錄項目修改的歷史紀錄** 這些功能很像我們經常使用的**大多數主流文本編輯器撤銷功能**，我們可以利用`ctrl + z`回撤將我們修改錯誤輸入的地方回撤，也可以用`ctrl + y`還原上次回撤時候的內容，這類功能滿足上述說的**版本控制**場景 ***** 但在程序開發來說整體代碼開發周期是一個長時間的工作，并且在回退的時候也許有可能是幾周之前的代碼，并不能像**文本編輯器撤銷功能**，采用**每次改動自動保存**的形式來保留修改歷史，將會導致改動歷史非常頻繁和無章可循，這樣，歷史代碼的查找、閱讀和回退就會很困難 ***** 因此開發過程中需要的是可以**主動提交改動**的機制，使用 `commit `命令把改動和對改動的描述信息提交，這次改動就被記錄到版本歷史中了。之后如果你希望回退到這個版本，就可以從**版本控制系統 VCS** 的歷史日志中方便地找到它 >[success] # 集中式和分布式 在程序開發過程中的版本控制有兩大類可以做到上面說到的結果`集中式（中央式）版本控制工具（svn）`和`分布式版本控制工具（git）`，版本控制上面已經解釋了下面就是關于`集中`和`分布` * **集中式**：所有歷史版本都在中央服務器上建立，本地客戶端只是一個開發環境，開發完成需要推送到服務器生成歷史版本，當需要回退到某個版本，也需要從中央服務器拉取，拉取的過程需要聯網，**中央服務器不能出現故障**   * **分布式**:就是將每個開發者的本地客戶端都是一個完整的倉庫，都能記錄歷史版本信息，無需聯網，也可以將生成的版本記錄回退到某個版本中，客戶端并不只提取最新版本的文件快照， 而是**把代碼倉庫完整地鏡像下來，包括完整的歷史記錄**，每一次的**克隆**操作，實際上都是一次對代碼倉庫的**完整備份**   * 分布式的本地倉庫、與集中式本地的區別。**本地倉庫是帶版本管理功能的，像可以離線做一些提交，回滾、查看歷史、分支操作**，而**集中式的本地備份如脫離服務器則做不上面的這些操作** >[danger] ##### 分布式優缺點 * **優點** 1. 大多數的操作可以在本地進行，所以速度更快，而且由于無需聯網，所以即使不在公司甚至沒有在聯網你也可以提交代碼、查看歷史，從而極大地減小了開發者的網絡條件和物理位置的限制 2. 由于可以提交到本地，所以你可以分步提交代碼，把代碼提交做得更細，而不是一個提交包含很多代碼難以 review 也難以回溯。 3. 集中式版本控制系統相比，分布式版本控制系統的安全性要高很多，因為每個人電腦里都有完整的版本庫，某一個人的電腦壞掉了不要緊，隨便從其他人那里復制一個就可以了。而集中式版本控制系統的中央服務器要是出了問題，所有人都沒法干活了。 * **缺點** 1. 由于每一個機器都有完整的本地倉庫，所以初次獲取項目（Git 術語：clone）的時候會比較耗時； 2. 由于每個機器都有完整的本地倉庫，所以本地占用的存儲比中央式 VCS 要高。 >[info] ## 使用分布式還是集中式場景 對于一般的程序項目而言，由于項目的大多數內容都是文本形式的代碼，所以工程的體積都并不是很大，再加上文本內容自身的特點，VCS 可以利用算法來把倉庫的體積極大地壓縮。這就導致，在實際中，Git 等分布式 VCS 的倉庫體積并不大，初次獲取項目的耗時和本地倉庫的存儲占用都很小。所以對于大多數的程序項目而言，分布式 VCS 「尺寸大、初次下載慢」的問題其實并不嚴重。 不過也有一些例外，比如游戲開發。游戲的開發中有大量的大尺寸數據和媒體文件，并且這些文件的格式也不容易壓縮尺寸，如果用分布式 VCS 會導致倉庫的體積非常龐大。所以一些大型游戲的開發會選擇中央式的 VCS 來管理代碼。 >[info] ## 參考 [Git 原理詳解及實用指南](https://juejin.cn/book/6844733697996881928)