​​20150821 [學習筆記] Git 版本控制(1) 
​
​(一)版本控制的緣由與概念
  • ​​當軟體工程師開發大型專案時，為了方便掌握專案開發情形以及在任何情況下都能夠回顧每個階段的設計版本，而使用的一種軟體工程技巧。
​​ 
​​ 
​
​(二)版本控制的類型 (整理自 "Git - 關於版本控制" & "從集中版本控制到分散式版本控制" )
  • ​​1.  本地端版本控制
  • ​​特點: 具有簡單的資料庫，用來記載檔案的所有變更記錄。(在同一台主機上)
  • ​​可同步: 讓所有開發者所做的變更能夠同步，最終得到相同的版本內容。
  • ​​可追溯: 能夠回顧開發過程所有時期的版本。
  • ​​可備份: 將所有檔案集中於檔案庫中，利於備份所有時期的版本。
  • ​​舉例: 
  • ​​(1) The Revision Control System (RCS)
​​ 
  • ​​2.  集中式版本控制系統 (CVCS: Centralized Version Control Systems)
  • ​​特點:
  • ​​保持同步: 開發者之間保持資料同步的狀態。
  • ​​方便管理: 檔案庫管理員可自由調整各個使用者的存取權限。
  • ​​維護容易:  集中式版本控制系統較散落在各使用者端的本地端資料庫來的容易維護。
  • ​​---------------------------------------------------------------------------------------------------------------------
  • ​​需線上作業: 開發者想要對檔案庫中的檔案進行操作，都必須在能夠連網的環境下進行(由於是集中控管，因此資料都集中在某一部能連網的遠端主機上)。
  • ​​有風險:  如果伺服器用來儲存資料庫的硬碟損毀，專案開發的所有資訊都會遺失。
  • ​​舉例:
  • ​​(1) Subversion (SVN)
  • ​​(2) Team Foundation Version Control (TFVC)
​​ 
  • ​​3.  分散式版本控制系統 (DVCS: Distributed Version Control System) :+1: 
  • ​​特點:
  • ​​完整的內容: 每一次的取出動作實際上就是完整備份整個儲存庫。 即使是整個系統損毀，也可將先前複製的資料還原到伺服器。 
  • ​​可離線作業: 對版本控制系統的操作，都可以直接在本機端的檔案庫中進行，包括提交、分支、等等的操作。
  • ​​版本獨立: 每個開發者可以擁有各自設計的專案版本，也可以互相分享。
​​ 
  • ​​集中式 Versus 分散式:
  • ​​分散式版本控管系統相較於集中式版本控管系統有以下優勢:
  • ​​(1) 支援本地操作
  • ​​(2)資料備份容易
  • ​​(3)功能強大
  • ​​(4)能夠彈性的進行版本上的分支與合併
  • ​​......
  • ​​舉例:
  1. ​​Git
  1. ​​Mecurial
​​ 
  • ​​ 
​
​(三)Git 簡介
  • ​​Git 的出現，來自於 Linux 之父 "Linus Torvalds" 開發 Linux kernel 的時候，因為早期的版本控制方法非常沒有效率，屬集中式控管，當 Linux kernel 這類複雜又龐大的專案在進行版本控管時，出現了許多問題。最早期 Linux kernel 採用 BitKeeper 進行版本控管，但後來 Linus Torvalds 基於 BitKeeper 與 Monotone 的使用經驗，設計出更棒的 Git 版控系統。原先 Git 只被設計成一個低階的版控工具，用來當做其他版控系統(SCM)的操作工具，後來才漸漸演變成一套完整的版本控制系統。
​​ 
  • ​​1. 使用特點
  • ​​Git 完全不需要伺服器端的支援就可以運作版本控制，因為每個人都有一份完整的儲存庫副本。
  • ​​因為每個人都有一份完整的儲存庫副本，所以每次提交版本變更時，都僅提交到本地的儲存庫而已，因此提交速度非常快，也不用網路連線，可大幅節省開發時間。
  • ​​由於每個人都有一份完整的儲存庫副本，代表著在使用 Git 版本控管時，沒有所謂的「權限控管」這件事，每個成員都能把儲存庫複製(clone)回來，也都可以在本地提交變更，沒有任何權限可以限制。使用 Git 時，唯一能設定的權限是，你有沒有權利存取上層儲存庫(upstream repository)或遠端儲存庫(remote repository)的權限。
  • ​​如果需要跟別人交換變更後的版本，隨時可以透過「合併」的方式進行，Git 擁有非常強悍的合併追蹤（merge tracing）能力。
  • ​​要合併多人的版本，你只要有存取共用儲存庫(shared repository)的權限或管道即可。 例如：在同一台伺服器上可以透過資料夾權限進行共用，或透過 SSH 遠端存取另一台伺服器的 Git 儲存庫，也可以透過 Web 伺服器等方式來共用 Git 儲存庫。
​​ 
  • ​​2. 重要設計
  • ​​支援非線性開發模式 (分散式開發模式)
  • ​​擁有快速的分支與合併機制，還包括圖形化的工具顯示版本變更的歷史路徑。
  • ​​每一次的分支只是某個 commit 的參考指標。
  • ​​分散式開發模型
  • ​​每個人參與開發的人都有完整的記錄。
  • ​​當開發人員第一次將 Git 版本庫複製(clone)下來後，完全等同於這份 Git 版本庫的「完整備份」。
  • ​​所有變更過的檔案與歷史紀錄，通通都會儲存在本機儲存庫(local repository)。
  • ​​相容於現有作業系統
  • ​​Git 版本庫其實就只是一個資料夾而已，資料夾中有許多相關的設定檔與各種 blob 物件檔案而已。
  • ​​可以用任何方式發布 (例: HTTP, FTP, rsync, SSH 皆可當成存取的媒介)
  • ​​有效率的處理大型專案
  • ​​由於完整的版本庫會複製(clone)一份在本機，該版本庫包含完整的檔案與版本變更紀錄，操作速度會比直接從遠端存取來的快。
  • ​​Git 版本控管不會因為專案越來越大、檔案越來越多，而導致速度變慢。
  • ​​歷史記錄保護
  • ​​Git 版控的過程，每次 commit 都會產生一組 hash id 編號，而且每個版本在變化的過程都會參考到這個 hash id，只要 hash id 無法比對的上，Git 就會無法運作，所以當專案越來越大，版本庫複製(clone)的越來越多份，你幾乎無法竄改檔案的內容或版本紀錄。
  • ​​每個人都有一份完整的版本庫，倘若改了原始的那份，所有人的版本庫就無法再合併回原本的版本庫了，所以你幾乎不可能任意竄改版本紀錄。
  • ​​以工具集為主的設計 (Toolkit-based design)
  • ​​Git 被設計成一個一個的工具軟體(指令列工具)，可以搭配不同工具來組合使用。
  • ​​彈性的合併策略 (Pluggable merge strategies)
  • ​​擁有良好設計的「不完整合併(incomplete merge)」 機制，以及多種可以完成合併的演算法，並在最後告知使用者為何無法自動完成合併，或通知你需要手動進行合併動作。
  • ​​檔案垃圾回收機制
  • ​​在使用 Git 的時候，可以任意中斷目前的操作或回復上一個操作。
  • ​​Git 的垃圾回收機制會自動清除檔案系統中無用的物件，使用者也可以手動清除。
  • ​​定期的封裝物件
  • ​​我們在 Git 中提到的 "物件" 其實就是代表版本庫中的一個檔案。在版本異動的過程中，專案中的程式碼或其他檔案會被更新，每次更新時，只要檔案內容不一樣，就會建立一個新的 "物件"，這些不同內容的檔案全部都會保留下來。
  • ​​可以將一群老舊的 "物件" 自動封裝進一個封裝檔(packfile)中，以改善檔案存取效率。
  • ​​那些新增的檔案還是會以單一檔案的方式存在著，也代表一個 Git 版本庫中的 "檔案" 就是一個 Git "物件"，但每隔一段時間就會需要重新封裝(repacking)。
  • ​​Git 會自動執行重新封裝等動作，但使用者也可以手動執行。
​​ 
​​ 
​​