溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇內容主要講解“SVN與Git版本控制的優缺點是什么”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“SVN與Git版本控制的優缺點是什么”吧!
集中式的版本控制系統都有一個單一的集中管理的服務器，保存所有文件的修訂版本，而協同工作的人們都通過客戶端連到這臺服務器，取出最新的文件或者提交更新。
每個版本庫有唯一的URL（官方地址），每個用戶都從這個地址獲取代碼和數據；
獲取代碼的更新，也只能連接到這個唯一的版本庫，同步以取得最新數據；
提交必須有網絡連接（非本地版本庫）；
提交需要授權，如果沒有寫權限，提交會失敗；
提交并非每次都能夠成功。如果有其他人先于你提交，會提示“改動基于過時的版本，先更新再提交”… 諸如此類；
沖突解決是一個提交速度的競賽：手快者，先提交，平安無事；手慢者，后提交，可能遇到麻煩的沖突解決。
好處：
每個人都可以一定程度上看到項目中的其他人正在做些什么。而管理員也可以輕松掌控每個開發者的權限。
缺點：中央服務器的單點故障。
若是宕機一小時，那么在這一小時內，誰都無法提交更新、還原、對比等，也就無法協同工作。如果中央服務器的磁盤發生故障，并且沒做過備份或者備份得不夠及時的話，還會有丟失數據的風險。最壞的情況是徹底丟失整個項目的所有歷史更改記錄，被客戶端提取出來的某些快照數據除外，但這樣的話依然是個問題，你不能保證所有的數據都已經有人提取出來。
Subversion原理上只關心文件內容的具體差異。每次記錄有哪些文件作了更新，以及都更新了哪些行的什么內容。
Git記錄版本歷史只關心文件數據的整體是否發生變化。Git 不保存文件內容前后變化的差異數據。
實際上，Git 更像是把變化的文件作快照后，記錄在一個微型的文件系統中。每次提交更新時，它會縱覽一遍所有文件的指紋信息并對文件作一快照，然后保存一個指向這次快照的索引。為提高性能，若文件沒有變化，Git 不會再次保存，而只對上次保存的快照作一連接。
在分布式版本控制系統中，客戶端并不只提取最新版本的文件快照，而是把原始的代碼倉庫完整地鏡像下來。這么一來，任何一處協同工作用的服務器發生故障，事后都可以用任何一個鏡像出來的本地倉庫恢復。這類系統都可以指定和若干不同的遠端代碼倉庫進行交互。籍此，你就可以在同一個項目中，分別和不同工作小組的人相互協作。你可以根據需要設定不同的協作流程。
另外，因為Git在本地磁盤上就保存著所有有關當前項目的歷史更新，并且Git中的絕大多數操作都只需要訪問本地文件和資源，不用連網，所以處理起來速度飛快。用SVN的話，沒有網絡或者斷開VPN你就無法做任何事情。但用Git的話，就算你在飛機或者火車上，都可以非常愉快地頻繁提交更新，等到了有網絡的時候再上傳到遠程的鏡像倉庫。換作其他版本控制系統，這么做幾乎不可能，抑或是非常麻煩。
Git中每個克隆(clone)的版本庫都是平等的。你可以從任何一個版本庫的克隆來創建屬于你自己的版本庫，同時你的版本庫也可以作為源提供給他人，只要你愿意。
Git的每一次提取操作，實際上都是一次對代碼倉庫的完整備份。
提交完全在本地完成，無須別人給你授權，你的版本庫你作主，并且提交總是會成功。
甚至基于舊版本的改動也可以成功提交，提交會基于舊的版本創建一個新的分支。
Git的提交不會被打斷，直到你的工作完全滿意了，PUSH給他人或者他人PULL你的版本庫，合并會發生在PULL和PUSH過程中，不能自動解決的沖突會提示您手工完成。
沖突解決不再像是SVN一樣的提交競賽，而是在需要的時候才進行合并和沖突解決。
Git 也可以模擬集中式的工作模式
Git版本庫統一放在服務器中
可以為 Git 版本庫進行授權：誰能創建版本庫，誰能向版本庫PUSH，誰能夠讀取（克隆）版本庫
團隊的成員先將服務器的版本庫克隆到本地；并經常的從服務器的版本庫拉（PULL）最新的更新；
團隊的成員將自己的改動推（PUSH）到服務器的版本庫中，當其他人和版本庫同步（PULL）時，會自動獲取改變
Git 的集中式工作模式非常靈活
你完全可以在脫離Git服務器所在網絡的情況下，如移動辦公／出差時，照常使用代碼庫
你只需要在能夠接入Git服務器所在網絡時，PULL和PUSH即可完成和服務器同步以及提交
Git提供 rebase 命令，可以讓你的改動看起來是基于最新的代碼實現的改動
Git 有更多的工作模式可以選擇，遠非 Subversion可比
Subversion的工作區和版本庫是截然分開的，而Git的工作區和版本庫是如影隨形的。
Subversion 的工作區和版本庫物理上分開：Subversion的版本庫和工作區是存儲在不同路徑下，一般是在不同的主機中，Subversion的企業級部署中，版本庫在服務器上，只能通過 https, http, svn 等協議訪問，而不能直接被用戶接觸到。
Subversion的工作區是一份版本庫在某個歷史狀態下的快照，如：版本庫最新的數據檢出到工作區。
Subversion的工作區中每一個目錄下都包含一個名為 .svn 的控制目錄（隱藏的目錄），該目錄的作用是：
① 標識工作區和版本庫的對應關系。
② 包含一份該子目錄下檢出文件的原始拷貝。當文件改動的差異比較或者本地改動的回退時，可以直接參考原始拷貝而無須通過網絡訪問遠程版本庫。
Subversion 的 .svn 控制目錄會引入很多麻煩：
① .svn 下的文件原始考本，會導致在目錄下按照文件內容搜索時，多出一倍的搜索時間和搜索結果。
② .svn 很容易在集成時，引入產品中，尤其是 Web 應用，將 .svn 目錄帶入Web服務器會導致安全隱患。因為一個不允許目錄瀏覽的Web目錄，可以通過 .svn/entries 文件查看到該目錄下可能存在的文件。
Git 的版本庫和工作區在同一個目錄下，工作區的根目錄有一個.git的子目錄，這個名為 .git的目錄就是版本庫本身，它是Git 用來保存元數據和對象數據庫的地方。該目錄非常重要，每次克隆鏡像倉庫的時候，實際拷貝的就是這個目錄里面的數據。所以千萬要小心刪除這個文件。
工作區中其他文件為工作區文件，可能是從 .git 中檢出的，或者是要檢入的，或者是運行產生的臨時文件等。
版本庫可以脫離工作區而存在，成為 bare（赤裸）版本庫。可以用 –bare參數來創建。但是工作區不能脫離版本庫而存在，即工作區的根目錄下必須有一個名為 .git 的版本庫克隆文件。
Git 的版本庫因為就在工作區中，能直接被用戶接觸到。
① 用戶可以編輯 .git/config 文件，修改配置，增添新的源
② 用戶可以編輯 .git/info/exclude 文件，創建本地忽略…
Git 的工作區中只在工作區的根目錄下有一個 .git 目錄，此外再無任何控制目錄。Git 工作區下唯一的 .git 目錄是版本庫，并非 .svn 的等價物，如果刪除了 .git 目錄，而又沒有該版本庫的其他鏡像（克隆）的話，你破壞了整個歷史，版本庫也永遠的失去了。
Git 在本地的 .git 版本庫，提供了完全的改動歷史。除了和其他人數據交換外，任何版本庫相關的操作都在本地完成，更多的本地操作，避免了冗長的網絡延遲，大大節省了時間。例如：查看 log，切換到任何歷史版本等操作都無須連接網絡。
Git如何保證安全：本地創建一個Git庫，因為工作區和庫是在同一個目錄中，如果工作區刪除了，或者所在的磁盤分區格式化了，數據不是全都沒有了么？其實我們可以這樣做：
① 在一個磁盤分區中創建版本庫（最好是用 –bare 參數創建），然后在另外的磁盤分區中克隆一個新的作為工作區。在工作區的提交要不時的PUSH到另外分區的版本庫，這樣就實現了本地的數據鏡像。你甚至可以在本地創建更多的版本庫鏡像，安全性要比Subversion的一個庫加上一個工作區安全。
② 另一個辦法：把你的版本庫共享給他人，當他人克隆了你的版本庫時，你就擁有了一個異地備份。
SVN的全局版本號和CVS的每個文件都獨立維護一套版本號相比，是一個非常大的進步。在看似簡單的全局版本號的背后，是Subversion提供對于事物處理的支持，每一個事物處理（即一次提交）都具有整個版本庫全局唯一的版本號。
Git的版本號則更進一步，版本號是全球唯一的。Git 對于每一次提交，通過對文件的內容或目錄的結構計算出一個SHA-1 哈希值，得到一個40位的十六進制字符串，Git將此字符串作為版本號。
所有保存在Git 數據庫中的數據都是用此40位的哈希值作索引的，而不是靠文件名。
使用哈希值作版本號的好處就是對于一個分布式的版本控制系統，每個人每次提交后形成的版本號都不會出現重復。另一好處是保證數據的完整性，因為哈希值是根據內容或目錄結構計算出來的，所以我們還可以據此來判斷數據內容是否被篡改。
SVN 的版本號是連續的，可以預判下一個版本號，而 Git 的版本號則不是。
因為 subversion 是集中式版本控制，很容易實現版本號的連續性。Git 是分布式的版本控制系統，而且 Git 采用 40 位長的哈希值作為版本號，每個人的提交都是各自獨立完成的，沒有先后之分（即使提交有先后之分，也由于PUSH/PULL的方向和時機而不同）。Git 的版本號雖然不連續，但是是有線索的，即每一個版本都有對應的父版本（一個或者兩個），進而可以形成一個復雜的提交鏈
Git 的版本號簡化：Git 可以使用從左面開始任意長度的字串作為簡化版本號，只要該簡化的版本號不產生歧義。一般采用7位的短版本號（只要不會出現重復的，你也可以使用更短的版本號）。
Subversion可以將整個庫檢出到工作區，也可以將某個目錄檢出到工作區。對于要使用一個龐大、臃腫的版本庫的用戶來說，部分檢出是非常方便和實際的。
但是Git只能全部檢出，不支持按照目錄進行的部分檢出。
在SVN中，從倉庫checkout的一個工作樹，每個子目錄下都維護著自己的.svn目錄，記錄著該目錄中文件的修改情況以及和服務器端倉庫的對應關系。所以SVN可以checkout部分路徑下的內容（部分檢出），而不用checkout整個版本庫或分支。
Subversion 有一條命令：svn export ，可以將 subversion 版本庫的一個目錄下所有內容導出到指定的目錄下。Subversion 需要 svn export 命令是因為該命令可以導出一個干凈的目錄，即不包含 .svn 目錄（包含配置文件和文件原始拷貝）。
Git 沒有部分檢出，這并不是說只有將整個庫克隆下來才能查看文件。有很多 git 工具，提供直接瀏覽git庫的功能，例如 gitweb, trac 的 git 版本庫瀏覽, redmine 的 git 版本庫瀏覽。
Git-submodule 可以實現版本庫的模塊化：Git 通過子模塊處理這個問題。
子模塊允許你將一個Git 倉庫當作另外一個Git倉庫的子目錄。這允許你克隆另外一個倉庫到你的項目中并且保持你的提交相對獨立。
Git 為什么沒有實現 svn export 的功能？由于git的本地倉庫信息完全維護在project根目錄的.git目錄下，（不像svn一樣，每個子目錄下都有單獨的.svn目錄）。所以，只要clone，checkout然后刪除.git目錄就可以了。
在SVN中，因為只有一個中心倉庫，所以所謂的遠程更新，也就是svn update ,通過此命令來使工作區和版本庫保持同步。
對于git來說，別人的改動是存在于遠程倉庫上的，所以git checkout命令盡管在某些功能上和svn中的update類似（例如取倉庫特定版本的內容），但是在遠程更新這一點上，還是不同的，不屬于git checkout的功能涵蓋范圍。
Git使用git fetch和git pull來完成遠程更新任務，fetch操作只是將遠程數據庫的object拷貝到本地，然后更新remotes head的refs，git pull 的操作則是在git fetch的基礎上對當前分支外加merge操作。
對于SVN來說，由于是中心式的倉庫管理形式，所以并不存在特殊的遠程提交的概念，所有的commit操作都可以認為是對遠程倉庫的更新動作。在工作區中對文件進行添加、修改、刪除操作要同步到版本庫，必須使用 commit命令。
add 命令，是將未標記為版本控制狀態的文件標記為添加狀態，并在下次提交時入庫。
delete命令，是通過SVN來刪除文件，并在下次提交后有效。
Subversion 有提交列表功能，即將某些文件加入一個修改列表，提交可以只提交處于該列表的文件。
Git 管理項目時，文件在三個工作區域中流轉：Git 的本地數據目錄，工作目錄以及暫存區域。暫存區域（stage）是介于 workcopy 和 版本庫HEAD 版本的一種中間狀態。所謂的暫存區域只不過是個簡單的文件，一般都放在git 目錄中。有時候人們會把這個文件叫做索引文件，不過標準說法還是叫暫存區域。
要將一個文件納入版本管理的范疇，首先是要用gitadd將文件納入stage的監控范圍，只有更新到stage中的內容才會在commit的時候被提交。另外，文件本身的改動并不會自動更新到stage中，每次的任何修改都必須重新更新到stage中去才會被提交。對于工作區直接刪除的文件，需要用 git rm 命令進行標記，在下次提交時，在版本庫中刪除。
工作區的文件改動（新增文件，修改文件，刪除文件），必須用 git add 或者 git rm 命令標識，使得改動進入 stage
提交只對加入 stage 的改動進行提交
如果一個文件改動加入 stage 后再次改動，則后續改動不改變 stage。即該文件的改動有兩個狀態，一個是標記到 stage 中并將在下次提交時入庫的改動，另外的后續改動則不被提交，除非再次使用 git add 命令將改動加入到 stage 中。
Git的stag讓你在提交的時候清楚的知道git將要提交哪些改動。除非提交的時候使用 -a 參數（不建議使用）。
我們可以從文件所處的位置來判斷其狀態：如果是git目錄中保存著的特定版本文件，就屬于已提交狀態；如果作了修改并已放入暫存區域，就屬于已暫存狀態；如果自上次取出后，作了修改但還沒有放到暫存區域，就是已修改狀態，如果取出后未進行修改則是未修改狀態。
在git中，因為有本地倉庫和remote倉庫之分，所以也就區別于commit 操作，存在額外的push命令，用于將本地倉庫的數據更新到遠程倉庫中去。git push 可以選擇需要提交的、更新的分支以及制定該分支在遠程倉庫上的名字。
幾乎每一種版本控制系統都以某種形式支持分支。使用分支意味著你可以從開發主線上分離開來，然后在不影響主線的同時繼續工作。在很多版本控制系統中，這是個昂貴的過程，常常需要創建一個源代碼目錄的完整副本，對大型項目來說會花費很長時間。
輕量級分支/里程碑的含義是，創建分支/里程碑的復雜度是o(1)，不會因為版本庫的愈加龐大而變得緩慢。在CVS中，創建分支的復雜度是o(n)的，導致大的版本庫的的分支創建非常緩慢。
Subversion輕量級分支和里程碑的實現是通過svn cp命令，即帶歷史的拷貝就是創建快速創建分支和里程碑的秘籍。Subversion的版本庫有特殊的設計，當你復制一個目錄，你不需要擔心版本庫會變得十分巨大—Subversion并不是拷貝所有的數據，相反，它只是建立了一個已存在目錄樹的入口。這種“廉價的拷貝”就是創建分支/里程碑是輕量級的原因。
由于Svn的分支和標簽是來自目錄拷貝，約定俗成是拷貝在 branches/和tags/目錄下。所謂分支，tag等概念都只是倉庫中不同路徑上的一個對象或索引而已，和普通的路徑并沒有什么本質的區別，誰也不能阻止在一個提交中同時修改不同分支中的數據。
里程碑是對某個歷史提交所起的一個別名，作為歷史的標記，是不應該被更改的。svn的里程碑要建立到 tags/目錄下，要求不要在tags/下的里程碑目錄下進行提交。但是誰也阻止不了對未進行權限控制的里程碑的篡改。
Git中的分支實際上僅是一個包含所指對象校驗和（40個字符長度SHA-1 哈希值）的文件，所以創建和銷毀一個分支就變得非常廉價。說白了，新建一個分支就是向一個文件寫入41個字節（版本號外加一個換行符）那么簡單，自然速度就很快了。 Git的實現與項目復雜度無關，它永遠可以在幾毫秒的時間內完成分支的創建和切換。這和大多數版本控制系統形成了鮮明對比。
Git的分支是完全隔離的，而Subversion則沒有。分支本來就應該是相對獨立的命名空間，一個提交一般只能發生在一個分支中。在Git中，其內部的對象層級依賴關系或許和SVN類似，但是其工作樹的視圖表現形式和SVN完全不同。工作樹永遠是一個完整的分支，不同的分支由不同的head索引去構建，你不可能在工作樹中同時獲得多個分支的內容。
Git使用的標簽有兩種類型：輕量級的（lightweight）和含附注的（annotated）。① 輕量級標簽就像是個不會變化的分支，實際上它就是個指向特定提交對象的引用。② 而含附注標簽，實際上是存儲在倉庫中的一個獨立對象，它有自身的校驗和信息，包含著標簽的名字，電子郵件地址和日期，以及標簽說明，標簽本身也允許使用GNU Privacy Guard (GPG) 來簽署或驗證。
Git的里程碑是只讀的，Git完全遵守歷史不可更改這一時空法則。用戶不能向git的里程碑中提交，否則里程碑就不是標記，而成了一個分支。當然Git允許用戶刪除里程碑再重新創建指定到不同歷史提交。
SVN中提供了一個功能switch，使用switch可以在同一個工作樹上，在不同的分支中進行切換。
Git在分支中進行切換使用的命令是checkout。
Git 和 Svn 的分支實現機制完全的不同，這也直接導致了 SVN 在分支合并中困難重重。盡管在 SVN 1.5 之后，通過 svn:mergeinfo 屬性引入了合并追蹤機制，但是在特定情況下，合并仍會出現很多困難。
當你在一個分支上工作數周或幾個月之后，主干的修改也同時在進行著，兩條線的開發會區別巨大，當你想合并分支回主干，可能因為太多沖突，已經無法輕易合并你的分支和主干的修改。
另一個問題，Subversion不會記錄任何合并操作，當你提交本地修改，版本庫并不能判斷出你是通過svn merge還是手工修改得到這些文件。所以你必須手工記錄這些信息（說明合并的特定版本號或是版本號的范圍）。
要解決以上的問題只有通過有規律的將主干合并到分支來避免，制定這樣一個政策：每周將上周的修改合并到分支，注意這樣做時需要小心，你必須手工記錄合并的過程，以避免重復的合并，你需要小心的撰寫合并的日志信息，精確的描述合并包括的范圍。這樣做看起來有點像是脅迫。
SVN 的版本號是連續的版本號。每一次新的提交都會版本號+1 ，而無論這個提交是在哪個分支中進行的。SVN一個提交可以同時修改不同分支的不同文件，因為提交命令可以在 /trunk, /branches, /tags 的上一級目錄執行。
SVN 的提交是單線索的，每一個提交（最原始的提交0除外）都只有一個父節點（版本號小一個的提交節點）
SVN 的提交鏈只有一條，僅從版本號和提交說明，我們無法獲得分支圖
SVN 的分支圖在某些工具（如烏龜SVN）可以提供，那是需要對提交內容進行檢查，對目錄拷貝動作視為分支，對 svn:mergeinfo 的改動視為合并，但這會由于目錄管理的靈活性，導致千奇百怪的分支圖表。
在 git 版本庫中創建分支的成本幾乎為零，所以，不必吝嗇多創建幾個分支。當第一次執行git-init時，系統就會創建一個名為”master”的分支。 而其它分支則通過手工創建。下面列舉一些常見的分支策略。
① 創建一個屬于自己的個人工作分支，以避免對主分支 master 造成太多的干擾，也方便與他人交流協作。
② 當進行高風險的工作時，創建一個試驗性的分支，扔掉一個爛攤子總比收拾一個爛攤子好得多。
③ 合并別人修改的時候，最好創建一個臨時的分支用來合并，合并完成后再“fatch”到自己的分支。
Git分支相關的操作命令
在Subversion中一旦完成向服務器的數據提交，你就沒有辦法再從客戶端追回，只能在后續的提交中修正（回退或者修改）等。因為Subversion作為集中式的版本控制，不能允許個人對已提交的數據進行篡改。Subversion具有一個非常重要的特性就是它的信息從不丟失，即使當你刪除了文件或目錄，它也許從最新版本中消失了 ，但這個對象依然存在于歷史的早期版本中。
Git則不同，Git是分布式版本控制系統，代碼庫是屬于個人，允許任意修改。Git通過對提交建立數字摘要來保證提交的唯一性和不可更改性，通過版本庫在多人之間的多份拷貝來保障數據的安全性。Git可以丟棄最新的一個或幾個提交，使用 git reset –hard命令可以永遠丟棄最新的一個或者幾個提交。
提交后如果對提交說明不滿意，如何實現對提交說明的修改：
⑴ Git可以使用命令git commit –amend修改提交說明。
Git可以修改最后一次提交說明，并不是說不能修改歷史版本的提交說明，只是修改最后一個版本提交說明擁有最簡單的命令；
Git修改提交說明，會改變提交的commit-id。即修改提交說明后，將產生一個新的提交；
Git可以通過git reset -hard ，git commit –amend，git rebase onto 等命令來實現對歷史提交的修改；
使用stg工具可以更為簡單的修改歷史提交的提交說明，包括提交內容；
⑵ Subversion也可以修改提交說明，是通過修改提交的svn:log版本屬性實現的：
不但可以修改最后一次提交的說明，并且可以修改歷史提交的提交說明；
Subversion修改提交說明是不可逆的操作，可能會造成說明被惡意修改；
Subversion缺省關閉修改提交說明的功能。管理員在設置了提交說明更改的郵件通知后，才可以打開該功能。
Git可以修改和重構歷史提交：使用Git本身的reset以及 rebase 命令可以修改或者重整/重構歷史提交，非常靈活。使用強大的 stg 可以使得歷史提交的重構更為簡潔，如果您對 stg 或者 Hg/MQ 熟悉的話。
Subversion 修改歷史提交，只能由管理員完成。
Subversion 是集中式版本控制系統，從客戶端一旦完成提交，就沒有辦法從客戶端撤銷提交。但是管理員可以在服務器端完成提交的撤銷和修改，但是操作過程和代價較大。
Subversion通過對文件目錄授權來實現權限管理，子目錄默認繼承父目錄的權限。但是也有缺憾，即權限不能在分支中繼承，不能對單個文件授權。例如為 /trunk及其子目錄的授權，不能繼承到分支或者標簽中相應的目錄下。
Git 的授權做不到Subversion那樣精細。Git的授權模型只能實現非零即壹式的授權，要么擁有全部的寫權限，要么沒有寫權限，要么擁有整個版本庫的讀權限，要么禁用。
從技術上將，Git可能永遠也做不到類似SVN的路徑授權（讀授權）：
如果允許按照路徑授權，則各個克隆的關系將不再是平等的關系，有的內容多，有的內容少，分布式的理念被破壞
如果只有部分路徑可讀，則克隆出來的提交和原始提交的提交ID可能不同。因為提交ID是和提交內容有關的，克隆中提交的部分內容被丟棄，勢必提交的ID也要重新計算
允許全部代碼可讀，只允許部分代碼可寫，在版本控制的管理下，是沒有多大實際意義的，而且導致了提交的邏輯上的不完整。
那么有什么辦法來解決授權的問題？
1.公司內部代碼開放。即代碼在公司內部，對項目組成員一視同仁的開放。
2.公司對代碼庫進行合理分解，對每個代碼庫分別授權。即某個代碼庫對團隊成員完全開放，對其它團隊完全封閉。
3.公司使用Subversion做集中式的版本控制，個人和/或團隊使用 Git-svn。這樣在無法改變公司版本控制策略時，程序員可以采用的變通之法。
4.Git服務器的部署實際上可以使用鉤子對分支和路徑進行寫授權，即可以控制誰能夠創建分支，能夠寫特定文件。
優點：
1、 管理方便，邏輯明確，符合一般人思維習慣。
2、 易于管理，集中式服務器更能保證安全性。
3、 代碼一致性非常高。
4、 適合開發人數不多的項目開發。
缺點：
1、 服務器壓力太大，數據庫容量暴增。
2、 如果不能連接到服務器上，基本上不可以工作，看上面第二步，如果服務器不能連接上，就不能提交，還原，對比等等。
3、 不適合開源開發（開發人數非常非常多，但是Google app engine就是用svn的）。但是一般集中式管理的有非常明確的權限管理機制（例如分支訪問限制），可以實現分層管理，從而很好的解決開發人數眾多的問題。
1、適合分布式開發，強調個體。
2、公共服務器壓力和數據量都不會太大。
3、速度快、靈活。
4、任意兩個開發者之間可以很容易的解決沖突。
5、離線工作。
缺點：
1、學習周期相對而言比較長。
2、不符合常規思維。
3、代碼保密性差，一旦開發者把整個庫克隆下來就可以完全公開所有代碼和版本信息。
到此，相信大家對“SVN與Git版本控制的優缺點是什么”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
