從人們開始用電腦開始就面臨著檔案版本控制的問題，從最原始的同一個文件多個不同命名錶示版本到使用本地的檔案版本管理，到後面集中式版本管理如2000年的SVN，到再後來的分散式的版本控制系統，如2005年的Git。到現在用的最多的版本控制庫依舊是SVN和Git，Git多用於個人、程式碼庫的管理。

與SVN的使用簡單相比，Gti是入門複雜，不過網上有大量視訊、文件教程，作為技術人員學習並使用理解Git會是一件很值的事。

雖然Git在分散式、分支管理等方便領先SVN，但並不代表它能代替SVN，兩者的理念設計原則不同，Git更適合文字檔案如程式碼庫的管理，尤其是並行遠端異地開發、分支較多的情況，而SVN則適用於集中式檔案版本管理、許可權控制嚴格等場景，我們要根據需求選對的工具。

Git的每次提交都會生成一個完整的檔案快照，對應一個檔案目錄tree。Git工程有工作區、暫存區、本地倉庫3個工作區域，引入暫存區是個不錯的設計，它能夠實現部分提交，記錄檔案的修改時間等資訊，提高檔案的比對效率。

與SVN分支策略相比，Git分支流程複雜了很多，除了要維護兩個長期的分支master和develop外，還有很多臨時性分支如hotfix等，甚至有些用SVN分支思維的同學還有疑問，這種模式分支合併後豈不是增加了很多重複測試的工作量，因為理論上分支測試後，任何程式碼的改動合併到其它分支都是要重新迴歸測試才可以的。對此要用Git分支思維才能更好理解，Git用這樣的分支策略就是為了應對實際中常出現的多人多版本並行開發的情況更方便有效率，如果實際開發過程中真像SVN開發分支線性向前迭代，則分支合併只是簡單的移動分支指標並不用重新測試（因為它們是同一套程式碼）。

rebase 會把從 Merge Base 以來的所有提交，以補丁的形式一個一個重新達到目標分支上。這使得目標分支合併該分支的時候會直接 Fast Forward，即不會產生任何衝突。提交歷史是一條線，這對強迫症患者可謂是一大福音。stash 將工作區與暫存區中的內容做一個提交，儲存起來，然後使用reset hard選項恢復工作區與暫存區內容。我們可以隨時使用 stash apply 將修改應用回來。stash 實現思路將我們的修改提交到本地倉庫，使用特殊的分支指標（.git/refs/stash）引用該提交，然後在恢復的時候，將該提交恢復即可。