從人們開始用電腦開始就面臨著文件版本控制的問題，從最原始的同一個文檔多個不同命名表示版本到使用本地的文件版本管理，到後面集中式版本管理如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）引用該提交，然後在恢復的時候，將該提交恢復即可。

2018第51周日