版本控制與git

自從第一台計算機出現，便出現了計算機語言．出現計算機語言之後，怎麼來管理這些**以及如何團隊協同合作開發一直成為業界頭疼的事．這篇文章便是介紹版本控制的發展史，以及如何實現版本管理的模型．

下圖為版本控制的發展歷史：

上圖基本上就是整個版本發展的歷史程序．

1　patch & diff

剛開始時，我們用的是簡單的diff與patch命令管理**．如果是乙個人開發的話，這樣的行為還可以忍受，但是隨著**架構的複雜性的加大，團隊合作越來越緊密.patch & diff已經越來越滿足不了開發人員的需求.這個時候急需一種管理軟體來管理這些**．cvs便應運而生．

2　cvs:1985

2023年,cvs 的創始人難以忍受團隊合作效率低下，在回家的路上思考如何設計一種軟體來管理**．

最初的cvs包括svn都是集中式版本控制．如圖：

上圖即是集中式管理控制軟體的模型，**由伺服器控制，各成員從伺服器checkout以及commit**．

相對於之前由diff&patch**控制的年代，cvs已經做的很不錯了．但是還不夠好．比如不支原子提供，沒有全域性號控制等等．當然這些都是細節的問題．為了解決這些細節問題，另乙個集中式管理軟體svn出現了．

3　svn:2001

svn也是集中式管理軟體，它的出現模型與cvs相同，只不過在細節上處理的比cvs更合理．因此在2023年到2023年，大家都轉向了svn．各種svn的開發外掛程式也跟著出現．

由於svn不僅僅是對於**管理，還會被用於文件的管理，因此圖形化介面的svn也跟著出現，雖然cvs也有圖形化介面，但是由於其沒有全域性版本號，因此流傳不廣．

在ubunut下的svn的圖形化介面：

如上圖所示的，版本下面的58便是全域性版本號，還有作者及修改日期都列舉在其中．當檔案被修改時，會顯示紅色表示與伺服器上的**有差異．

雖然svn已經做的很不錯了，但是由於**管理必須得有伺服器存在，對於使用者來說是一種極大的制約，分布式管理軟體解決了這個難題．

4.git

當集中式版本控制發展到頂峰時，各種分布式商業版本已經出現．只不過開源的分布式版本控制軟體一直沒有人做．

分布式版本控制的模型如下：

每個使用者都是伺服器，各個使用者之間可以進行**推拉的操作．使用者的commit行為只是提交到本地伺服器裡，這樣使用者不再被離線提交所困擾．

說到這裡，我們應該感謝那位核心成員，如果不是他的這種行為，就不會有git的今天．

git的兩大優點：1.開源.2.分布式．

它有支援離線提交，而且也對原子操作的支援，還有快速的分支建立切換等等優點,可以說是集萬千寵愛於一身．

5.結束語

版本控制發展到今天，分布式管理是必然的趨勢．也許將來會有更合理更人性化的分布管理軟體，但是現在git由於其開源及分布式成為一種發展趨勢．