從人們開始用電腦開始就面臨著文件版本控制的問題，從最原始的同一個(gè)文檔多個(gè)不同命名表示版本到使用本地的文件版本管理，到后面集中式版本管理如2000年的SVN，到再后來的分布式的版本控制系統(tǒng)，如2005年的Git。到現(xiàn)在用的最多的版本控制庫依舊是SVN和Git，Git多用于個(gè)人、代碼庫的管理。

與SVN的使用簡單相比，Gti是入門復(fù)雜，不過網(wǎng)上有大量視頻、文檔教程，作為技術(shù)人員學(xué)習(xí)并使用理解Git會是一件很值的事。

雖然Git在分布式、分支管理等方便領(lǐng)先SVN，但并不代表它能代替SVN，兩者的理念設(shè)計(jì)原則不同，Git更適合文本文件如代碼庫的管理，尤其是并行遠(yuǎn)程異地開發(fā)、分支較多的情況，而SVN則適用于集中式文件版本管理、權(quán)限控制嚴(yán)格等場景，我們要根據(jù)需求選對的工具。

Git的每次提交都會生成一個(gè)完整的文件快照，對應(yīng)一個(gè)文件目錄tree。Git工程有工作區(qū)、暫存區(qū)、本地倉庫3個(gè)工作區(qū)域，引入暫存區(qū)是個(gè)不錯(cuò)的設(shè)計(jì)，它能夠?qū)崿F(xiàn)部分提交，記錄文件的修改時(shí)間等信息，提高文件的比對效率。

與SVN分支策略相比，Git分支流程復(fù)雜了很多，除了要維護(hù)兩個(gè)長期的分支master和develop外，還有很多臨時(shí)性分支如hotfix等，甚至有些用SVN分支思維的同學(xué)還有疑問，這種模式分支合并后豈不是增加了很多重復(fù)測試的工作量，因?yàn)槔碚撋戏种y試后，任何代碼的改動(dòng)合并到其它分支都是要重新回歸測試才可以的。對此要用Git分支思維才能更好理解，Git用這樣的分支策略就是為了應(yīng)對實(shí)際中常出現(xiàn)的多人多版本并行開發(fā)的情況更方便有效率，如果實(shí)際開發(fā)過程中真像SVN開發(fā)分支線性向前迭代，則分支合并只是簡單的移動(dòng)分支指針并不用重新測試（因?yàn)樗鼈兪峭惶状a）。

rebase 會把從 Merge Base 以來的所有提交，以補(bǔ)丁的形式一個(gè)一個(gè)重新達(dá)到目標(biāo)分支上。這使得目標(biāo)分支合并該分支的時(shí)候會直接 Fast Forward，即不會產(chǎn)生任何沖突。提交歷史是一條線，這對強(qiáng)迫癥患者可謂是一大福音。stash 將工作區(qū)與暫存區(qū)中的內(nèi)容做一個(gè)提交，保存起來，然后使用reset hard選項(xiàng)恢復(fù)工作區(qū)與暫存區(qū)內(nèi)容。我們可以隨時(shí)使用 stash apply 將修改應(yīng)用回來。stash 實(shí)現(xiàn)思路將我們的修改提交到本地倉庫，使用特殊的分支指針（.git/refs/stash）引用該提交，然后在恢復(fù)的時(shí)候，將該提交恢復(fù)即可。

?

總結(jié)

以上是生活随笔為你收集整理的2018第51周日的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。