30 天精通 Git 版本控管 (01)：認識 Git 版本控管 [轉載於iT邦幫忙]

雖然說本次文章的主題是「30 天精通 Git 版本控管」，不過，說實在的，還真有點言過其實了，因為 Git 博大精深，有非常多細節可以探究，如果真的要應用在工作上，學幾天可以真正上手呢？每天學一點，連續學習 30 天，似乎是個合理的數字 (或太多?)，如果有一個工具大家都要用，而且要立刻上手的工具，如果學 30 天都還不知道怎麼活用，那這學習門檻也太高了些。因此我想，這個系列的文章，主要還是專注於「如何在 30 天內學會 Git 版本控管，而且必須要能熟練的應用在實務開發工作上」，這才是本系列的真正目的，那些繁瑣的細節，我不會特別強調，但總是有些重要的概念與細節還是不能錯過，我會嘗試在每一個主題中提到一部份，一有機會就會深入探討，希望大家可以透過做中學，深刻體會 Git 版本控管的強大魅力。

轉換的契機

這幾個月，公司因為有個大型專案，參與開發人數超過 12 人，最後大家決議採用 Git 作為本次專案的版本控管機制，與其說我們採用了 Git 版本控管，其實真正採用的原因是「我們選擇使用 GitHub 當成我們的版控平台」，原因就是 GitHub 平台實在整合得太好，完整的 Git 版控支援、議題追蹤與管理、線上 Wiki 文件管理、友善的原始碼審核(Code Review)介面。這些特性，都能有效協助我們在多人協同開發的過程中，減少團隊溝通的問題。

剛開始接觸 Git 說實在挺辛苦的，因為 Git 版本控管的觀念，實在與 Subversion 差太多，沒有辦法很直覺的去體會其差異，就算給了你 GUI 圖形化工具介面，你也不見得就會使用。你知道的，一個強大又好用的工具在你手上，「錯誤的使用方式」比「不會用」還可怕！說穿了，就是你必須先建立一套思維模式(Mindset)，了解 Git 的運作原理，然後再上手使用 Git 相關工具 (無論是指令列工具或圖形化介面工具)，才是正途！

學習的方法

我在剛學習 Git 的時候，看了好幾本書 (其實是挑重點看)，也看了許多線上的文章與簡報，甚至還看了好幾部教學影片，看著看著，確實可以學會如何使用 Git 工具，我覺得並不會太過艱深。不過，Git 的指令與參數非常多，完全超出大腦能記憶的範圍，除非每天使用，否則哪有可能一天到晚打指令進行版控，如果每次要使用 Git 指令都要查書的話，那這也太沒效率了點，當下的我就直覺地認為，學習 Git 最終還是要回歸到好用的 GUI 工具，否則這東西在團隊中可能不容易推廣。

再者，因為 Git 是屬於「分散式版本控管」機制，當開發人數開始變多，版本庫又開始變成一人一份時，在第一次進行多人分支與合併的過程時，大家都飽受煎熬，而且持續一段不短的時間。雖然公司內部有先進行技術分享，不過由於大家都是第一次學，那些 Git 的抽象概念，還沒辦法深植人心，只能基於 Git 的使用方法進行分享，例如工具怎麼用、有哪些常用的指令、甚麼特殊的情況下應該下甚麼指令，諸如此類的。過程中就算說出了複雜的原理，由於大家對於 Git 的認知還很模糊，不同人對 Git 版控方式的理解也不盡相同，所吸收到的知識與概念，也不一定一致。所以，雖然上完課了，大家還是需要好幾天的時間不斷謀合，相互討論，互相解決問題，如果你只有一人使用 Git 的話，確實不容易感受 Git 帶來的好處，也恐怕不容易堅持下去。

所以，我認為，要學好 Git 版本控管，若先知道以下幾點，也許比較容易學會：

* 先擁有 Git 基礎觀念，透過下指令的方式學習是最快的方式，不要跳過這一段
* 找多一點人跟你一起學 Git 版本控管，最好能直接用在實務的開發工作上
* 團隊中最好要有幾個先遣部隊，可以多學一點 Git 觀念，好分享給其他人，或有人卡關時，能適時提供協助
* 了解 Git 屬於「分散式版本控管」，每個人都有一份完整的儲存庫(Repository)，所以必須經常合併檔案
* 使用 Git 的時候，分支與合併是常態，但只要有合併，就會有衝突，要學會如何解決衝突

認識 Git 版本控管

Git 的出現，來自於 Linux 之父 "Linus Torvalds" 開發 Linux kernel 的時候，因為早期的版本控制方法非常沒有效率，屬集中式控管，當 Linux kernel 這類複雜又龐大的專案在進行版本控管時，出現了許多問題。最早期 Linux kernel 採用 BitKeeper 進行版本控管，但後來 Linus Torvalds 基於 BitKeeper 與 Monotone 的使用經驗，設計出更棒的 Git 版控系統。原先 Git 只被設計成一個低階的版控工具，用來當做其他版控系統(SCM)的操作工具，後來才漸漸演變成一套完整的版本控制系統。

有趣的是，Linus Torvalds 改採 Git 進行版本控管初期，由於 Git 太過複雜，許多版控觀念跟以往差異太大，也受到世界各地開放原始碼社群的反對，但經過幾年的努力與發展，操作 Git 的相關工具也越來越成熟，才漸漸平撫反對的壓力，從 2013 年的市場調查看來，全世界已有 30% 的開放原始碼專案改採 Git 進行版本控管，這是個非常驚人的市占率，意謂著 Git 絕對有其驚豔之處，不好好研究一番還不行呢！

講到 Git 的架構，完全是基於 Linus Torvalds 在維護 Linux kernel 這個大型專案時得到的經驗，以及他本身在檔案系統優化方面的豐富經驗進行設計，也因為這樣，Git 包含了以下幾個重要的設計：

* 強力支援非線性開發模式 (分散式開發模式)

• Git 擁有快速的分支與合併機制，還包括圖形化的工具顯示版本變更的歷史路徑。
• Git 非常強調分支與合併，所以版本控管的過程中，你會不斷的在執行分支與合併動作。
• Git 的分支機制非常輕量，沒有負擔，每一次的分支只是某個 commit 的參考指標而已。
  * 分散式開發模型
• 參與 Git 開發的每個人，都將擁有完整的開發歷史紀錄。
• 當開發人員第一次將 Git 版本庫複製(clone)下來後，完全等同於這份 Git 版本庫的「完整備份」。
• 整個版本庫中所有變更過的檔案與歷史紀錄，通通都會儲存在本機儲存庫(local repository)。
  * 相容於現有作業系統
• Git 版本庫其實就只是一個資料夾而已，資料夾中有許多相關的設定檔與各種 blob 物件檔案而已。
• Git 版本庫可以用任何方式發布，所以你用 HTTP, FTP, rsync, SSH 甚至於用 Git protocol 都可以當成存取 Git 版本庫的媒介，相容性極高。
  * 有效率的處理大型專案
• 由於完整的版本庫會複製(clone)一份在本機，該版本庫包含完整的檔案與版本變更紀錄，所以針對版本控管中的各種檔案操作速度，將會比直接從遠端存取來的快上百倍之多。
• 這也代表著，Git 版本控管不會因為專案越來越大、檔案越來越多，而導致速度變慢。
  * 歷史紀錄保護
• Git 版控的過程，每次 commit 都會產生一組 hash id 編號，而且每個版本在變化的過程都會參考到這個 hash id，只要 hash id 無法比對的上，Git 就會無法運作，所以當專案越來越大，版本庫複製(clone)的越來越多份，你幾乎無法竄改檔案的內容或版本紀錄。
• 請記得: 每個人都有一份完整的版本庫，你改了原始的那份，所有人的版本庫就無法再合併回原本的版本庫了，所以你幾乎不可能任意竄改版本紀錄。
  * 以工具集為主的設計 (Toolkit-based design)
• Git 被設計成一個一個的工具軟體(指令列工具)，你可以很輕易的組合不同工具的使用，使用上非常彈性。
  * 彈性的合併策略 (Pluggable merge strategies)
• Git 有一個擁有良好設計的「不完整合併(incomplete merge)」 機制，以及多種可以完成合併的演算法，並在最後告知使用者為何無法自動完成合併，或通知你需要手動進行合併動作。
  * 被動的垃圾回收機制
• 在使用 Git 的時候，若想要中斷目前的操作或回復上一個操作，都是可以的，你完全可以不必擔心可能有其中一個指令下錯，或指令執行到一半當機等問題。
• Git 的垃圾回收機制，其實就是那些殘留在檔案系統中的無用檔案，這個垃圾回收機制只會在這些無用的物件累積一段時間後自動執行，或你也可以自行下達指令清空它。例如: git gc --prune
  * 定期的封裝物件
• 我們在 Git 中提到的 "物件" 其實就是代表版本庫中的一個檔案。而在版本異動的過程中，專案中的程式碼或其他檔案會被更新，每次更新時，只要檔案內容不一樣，就會建立一個新的 "物件"，這些不同內容的檔案全部都會保留下來。
• 你應該可以想像，當一個專案越來越大、版本越來越多時，這個物件會越來越多，雖然每個檔案都可以各自壓縮讓檔案變小，不過過多的檔案還是會檔案存取變得越來越沒效率。因此 Git 的設計有個機制可以將一群老舊的 "物件" 自動封裝進一個封裝檔(packfile)中，以改善檔案存取效率。
• 那些新增的檔案還是會以單一檔案的方式存在著，也代表一個 Git 版本庫中的 "檔案" 就是一個 Git "物件"，但每隔一段時間就會需要重新封裝(repacking)。
• 照理說 Git 會自動執行重新封裝等動作，但你依然可以自行下達指令執行。例如: git gc
• 如果你要檢查 Git 維護的檔案系統是否完整，可以執行以下指令: git fsck