version-control svn教學 - 我應該使用SVN還是Git?




svn比較 svn使用 (18)

我正在開始一個新的分佈式項目。 我應該使用SVN還是Git?為什麼?


Answers

在做了更多的研究之後,並回顧一下這個鏈接: https://git.wiki.kernel.org/articles/g/i/t/GitSvnComparison_cb82.htmlhttps://git.wiki.kernel.org/articles/g/i/t/GitSvnComparison_cb82.html

(以下摘錄):

  • 速度非常快。 我沒有使用過其他的SCM能夠跟上它,並且我使用了很多,包括Subversion,Perforce,darcs,BitKeeper,ClearCase和CVS。
  • 它完全分佈。 存儲庫所有者不能規定我的工作方式。 我可以在我的筆記本電腦上斷開連接時創建分支並提交更改,然後與其他任何數量的存儲庫進行同步。
  • 同步可以發生在很多媒體上。 一個SSH通道,通過HTTP通過WebDAV,通過FTP,或通過發送電子郵件持有由郵件接收者應用的補丁。 中央存儲庫不是必需的,但可以使用。
  • 分支甚至比在Subversion中更便宜。 創建分支與將41字節文件寫入磁盤一樣簡單。 刪除分支與刪除該文件一樣簡單。
  • 與Subversion分支不同,它帶有完整的歷史記錄。 而不必執行一個奇怪的副本並瀏覽副本。 在使用Subversion時,我總是覺得很難看到分支創建之前分支上的文件的歷史記錄。 from #git:spearce:我不明白頁面中有關SVN的一件事。 我在SVN上創建了一個分支,瀏覽歷史記錄顯示了整個歷史在分支中的一個文件
  • 分支合併在Git中更簡單和更自動。 在Subversion中,你需要記住你合併的最後一個版本是什麼,所以你可以生成正確的合併命令。 Git自動執行此操作,並始終做對。 這意味著將兩個分支合併在一起時犯錯的可能性較小。
  • 分支合併記錄為存儲庫適當歷史記錄的一部分。 如果我將兩個分支合併在一起,或者如果我將一個分支合併到它來自的後備箱中,那麼合併操作會被記錄為轉倉歷史記錄的一部分,因為這是由我執行的以及何時執行的。 在日誌中正確執行合併的人很難爭辯。
  • 創建一個倉庫是一個簡單的操作:mkdir foo; cd foo; git init就是這樣。 這意味著我為這些日子的一切創建了一個Git倉庫。 我傾向於每個類使用一個存儲庫。 這些存儲庫中的大多數在磁盤上低於1 MB,因為它們只存儲講義,作業分配和我的LaTeX答案。
  • 存儲庫的內部文件格式非常簡單。 這意味著修復非常容易,但更好,因為它非常簡單,很難修復。 我不認為有人曾經有一個Git倉庫被損壞。 我已經看到了使用fsfs自身損壞的Subversion。 我已經看到Berkley DB損壞了很多次,以至於我將代碼信任到Subversion的bdb後端。
  • Git的文件格式非常適合壓縮數據,儘管它是一種非常簡單的格式。 Mozilla項目的CVS存儲庫約為3 GB; 它在Subversion的fsfs格式中大約為12 GB。 在Git中大約有300 MB。

閱讀完所有內容後,我確信Git是最佳選擇(儘管存在一點學習曲線)。 我也在Windows平台上使用過Git和SVN。

在閱讀完上面的內容之後,我很想听聽其他人說的話嗎?


沒有真正回答你的問題,但如果你想分佈式修訂控制的好處 - 聽起來像你這樣做 - 而且你正在使用Windows我認為你最好使用Mercurial而不是Git,因為Mercurial具有更好的Windows支持。 Mercurial也有一個Mac端口。


您必須使用DVCS,這就像源代碼管理中的一次飛躍。 我個人使用Monotone,並加快開發時間。 我們將它用於Windows,Linux和Mac,並且它非常穩定。 我甚至有buildbot在每個平台上每晚構建項目。

DVCS在分發時通常意味著您將創建一個中央服務器,僅供人們向其中推送更改。


肯定是svn ,因為Windows在充其量是git世界中的二等公民(更多細節請參見http://en.wikipedia.org/wiki/Git_(software)#Portability )。

更新:對於斷開的鏈接抱歉,但我已經放棄嘗試使用包含圓括號的URI工作。 [現在鏈接已修復。 -ed]


你嘗試過Bazaar嗎?

這是非常好的,非常實用的(製造Ubuntu的人)做到這一點,因為他們不喜歡市場上的其他任何東西......


我會建立一個Subversion版本庫。 通過這樣做,單個開發人員可以選擇是使用Subversion客戶端還是使用Git客戶端(使用git-svn )。 使用git-svn並不能為您提供完整的Git解決方案帶來的所有好處,但它確實為單個開發人員提供了對自己工作流程的大量控制。

我相信,在Git在Windows和Unix和Mac OS X上工作的時間相對較短(因為您問過)。

Subversion有優秀的Windows工具,比如用於Explorer集成的TortoiseSVN和用於Visual Studio集成的AnkhSVN。


主要的一點是,Git是一個分佈式VCS,而Subversion是一個集中的VCS。 分佈式VCS有點難以理解,但有很多優點。 如果你不需要這個優點,Subversion可能會是更好的選擇。

另一個問題是工具支持。 您計劃使用哪些工具更好地支持哪種VCS?

編輯:三年前我這樣回答:

而Git目前只能通過Cygwin或MSYS在Windows上運行。 Subversion從一開始就支持Windows。 由於Git的git解決方案可能適用於您,因此可能存在問題,因為大多數Git開發人員都在Linux上工作,從一開始就無法在頭腦中實現可移植性。 目前我寧願在Windows下開發Subversion。 在幾年內,這可能是無關緊要的。

現在世界已經改變了一點點。 現在,Git在Windows上有很好的實現。 儘管我沒有在Windows上進行過測試(因為我不再使用這個系統),但我相當確信,所有主要的VCS(SVN,Git,Mercurial,Bazaar)都有適當的Windows實現。 SVN的這一優勢消失了。 其他點(集中式與分佈式以及工具支持檢查)保持有效。


很少引用SVN的2個關鍵優勢:

  1. 大文件支持。 除了代碼之外,我使用SVN來管理我的主目錄。 SVN是唯一不會在我的TrueCrypt文件中窒息的VCS(請分辨我是否有另一個可有效處理500MB +文件的VCS)。 這是因為差異比較是流式傳輸的(這是非常重要的一點)。 Rsync是不可接受的,因為它不是雙向的。

  2. 部分存儲庫(subdir)結帳/簽入。 Mercurial和bzr不支持這一點,而git的支持是有限的。 這在團隊環境中很糟糕,但如果我想從我的家庭目錄中檢查另一台計算機上的某些內容,這是非常寶貴的。

只是我的經驗。


我已經使用了SVN很長一段時間,但是每當我使用Git時,我都覺得Git功能強大,重量輕,雖然涉及到一點學習曲線但比SVN好。

我注意到的是,隨著SVN項目的發展,每個SVN項目都將成為一個非常大的項目,除非它被導出。 GIT項目(與Git數據一起)的體積非常輕。

在SVN中,我將開發人員從新手處理到專家,新手和中間人似乎在從另一個SVN項目複製一個文件夾以重新使用它時引入了文件衝突。 然而,我認為在Git中,您只需複製文件夾並且它可以工作,因為Git不會在其所有子文件夾中引入.git文件夾(就像SVN一樣)。

自從很長時間以來,與SVN一起處理了很多事情之後,我終於考慮將我的開發人員和我轉移到Git上,因為它很容易協作和合併工作,而且一個很大的優點是可以盡可能多地承諾本地副本的更改然後最終推送到服務器上的分支,與SVN不同(我們必須不時地在服務器上的存儲庫中提交更改)。

任何人都可以幫助我決定是否應該真正使用Git?


這歸結為:

你的發展是線性的嗎? 如果是這樣,你應該堅持使用Subversion。

另一方面,如果您的開發不會是線性的,這意味著您需要為不同的更改創建分支,然後將這些更改合併回主開發線(Git已知為主分支),那麼Git將執行對你更重要。


有趣的是:我在Subversion Repos中託管項目,但通過Git Clone命令訪問它們。

請閱讀Google代碼項目中的使用Git開發

儘管谷歌代碼本身就會說Subversion,但是在開發過程中可以輕鬆使用Git。 搜索“git svn”表明這種做法非常普遍,我們也鼓勵您嘗試一下。

在Svn Repository上使用Git使我受益匪淺:

  1. 我可以在多台機器上工作,承擔和從他們拉出
  2. 我有一個中央 backup/public svn存儲庫供其他人檢查
  3. 他們可以自由使用Git

我從來沒有理解過這種“在Windows上不擅長”的概念; 我完全在Windows下開發,我從來沒有任何問題與Git。

我肯定會推薦git over subversion; 它只是非常多才多藝,並且允許“顛覆式開發”以顛覆方式永遠不可能實現的方式。 它幾乎可以在任何可以想像的平台上使用,並且具有比您可能使用的更多功能。


如果你的團隊已經熟悉cvs或svn等版本和源代碼控制軟件,那麼對於一個簡單和小型的項目(比如你聲稱的),我建議你堅持使用SVN。 我對svn非常滿意,但對於我在django上進行的當前電子商務項目,我決定在git上工作(我在svn模式下使用git,也就是說,通過一個集中的repo,從而與至少一個其他開發者合作)。 另一位開發人員對SVN感到滿意,而其他人的經驗可能會有所不同,但我們兩人對於這個小型項目都非常不滿。 (如果它很重要,我們都是硬核Linux用戶。)

當然,你的里程可能會有所不同。


在Windows下,Git本身並不支持。 它針對Posix系統進行了優化。 然而運行Cygwin或MinGW可以讓你運行Git成功。

現在我更喜歡Git而不是SVN,但是如果你來自CVS,SVN land,需要一段時間才能超過門檻。


我會選擇SVN,因為它更廣泛和更廣為人知。

我猜,Git對Linux用戶會更好。


這裡是我從一些重複的問題中刪除了關於Git與SVN(2009年9月)的答案的副本。

更好? 除了通常的鏈接WhyGitIsBetterThanX ,它們是不同的:

一個是基於廉價的分支和標籤拷貝的中央VCS另一個(Git)是基於修訂圖的分佈式VCS。 另請參閱VCS的核心概念

第一部分產生了一些錯誤的評論,假設這兩個程序(SVN和Git)的基本目的是相同的,但是它們的實現方式有很大不同。
為了澄清SVN和Git之間根本區別 ,讓我換個說法:

  • SVN是版本控制的第三個實現: RCS,然後是CVS,最後是SVN管理版本化數據的目錄。 SVN提供了VCS特性(標籤和合併),但它的標籤只是一個目錄副本(就像一個分支,除非你不能“接觸”標籤目錄中的任何東西),它的合併仍然很複雜,目前基於元添加數據以記住已經合併的內容。

  • Git是一個文件內容管理 (一種合併文件的工具), 演變成一個真正的版本控制系統 ,基於提交的DAG(有向無環圖 ),其中分支是數據歷史的一部分(而不是數據本身),標籤是一個真正的元數據。

要說他們不是“根本上”不同,因為你可以達到同樣的目的,解決同樣的問題,在很多層面上......是純粹的錯誤。

  • 如果你有很多複雜的合併,用SVN做它們會更長,更容易出錯。 如果你必須創建許多分支,你將需要管理它們並合併它們,再次使用Git比使用SVN更容易,特別是在涉及大量文件時(速度變得重要)
  • 如果您正在進行部分合併工作,那麼您將利用Git臨時區域(索引)僅提交您需要的內容,將其餘部分隱藏起來,然後在另一個分支上繼續。
  • 如果您需要脫機開發...以及Git,您總是可以通過自己的本地存儲庫“在線”,無論您希望使用其他存儲庫的工作流程如何。

儘管如此,舊的(刪除)答案的評論仍然堅持:

VonC:你在實施方面的根本區別(差異是非常基本的,我們都明確同意這一點),目的不同。
它們都是用於相同目的的工具:這就是為什麼許多以前使用過SVN的團隊已經成功地將它轉儲為Git。
如果他們沒有解決同樣的問題,這種可替代性就不存在。

,我回答說:

“可替代性”......有趣的術語( 用於計算機編程 )。
當然,Git幾乎不是SVN的子類型。

你可以在兩者上實現相同的技術特徵(標籤,分支,合併),但Git並不妨礙你的工作,並且讓你專注於文件的內容 ,而不必考慮工具本身。

你當然不能(總是)只用Git替換SVN,而不改變該程序的任何期望屬性(正確性,任務執行,...)“(這是對前述可替換性定義的引用):

  • 一個是擴展版本工具,另一個是真正的版本控制系統。
  • 一個適用於具有簡單合併工作流程和(不太多)並行版本的小型到中型整體項目。 SVN就足夠了,你可能不需要所有的Git特性。
  • 另一個允許基於多個組件( 每個組件一個回購 )的大中型項目,在復雜合併工作流程中的多個分支之間合併大量文件,在分支中使用並行版本,改進合併等等。 你可以用SVN來完成,但你用Git更好。
    SVN根本無法用任何合併工作流管理任何規模的項目。 Git可以。

再次, 它們的本質是根本不同的 (然後導致不同的實現,但這不是重點)。
一個將修訂控件看作目錄和文件,另一個只能看到文件的內容(以至於空目錄甚至不會在Git中註冊!)。

一般的最終目標可能是相同的,但不能以相同的方式使用它們,也不能解決同一類問題(範圍或複雜度)。



git add myfile.txt #這將把你的文件添加到提交列表中

與此命令完全相反的是,

git reset HEAD myfile.txt  # this will undo it. 

所以,你將處於以前的狀態。指定將再次處於未跟踪列表(先前狀態)。

它將使用指定的文件重置您的頭部。所以,如果你的頭沒有它的意思,它只會重置它





git svn version-control