Subversion 用得好好的,為什麼要改用 Git 呢?
記得剛開始用 Subversion 時,它在 Windows 平台上的工具也還不是那麼方便,光是安裝就要手動設定一堆東西。現在,Subversion 伺服器已經幾乎是點下一步、下一步的方式就能安裝完成了,非常方便。而且,現有的軟體專案、寫作等工作,也都在是用 Subversion 來管理版本。在已經投資不少學習成本、且用得很習慣的情況下,要換另外一套版本管理系統總是會有一些阻力。
更順暢的工作流程
其實我 lag 很久了。沒有改用 Git,主要就是因為習慣問題,以及考慮到已經付出的學習成本,和沒有一個讓我覺得非換不可的理由。但是最近由於經常使用筆電,而且網路經常碰到無法連線的狀態(有時候是筆電所在的環境無法連網,有時候是伺服器離線),以至於有些本機的修改成果無法立即 commit 成一個修訂版次。這個時候,如果我還要繼續修改別的東西(例如修正另一個 bug),往往就會跟剛才的修改混在一起 commit,而且是要等到可連上網路時才能 commit。這樣的時間差,很容易造成一些遺漏或混亂,無形中就增加了成本和風險。我希望就算無法連接伺服器,還是能夠依目前的進度先 commit,並且繼續做後續的修改,這樣我就不用在那裡空等,也不用擔心自己等到網路可連線時,已經忘記那些檔案的 commit 先後次序。Git 可以做到這點。
快速
Git 之所以反應迅速,主要是因為分散式架構的緣故。在此架構下,版本庫的完整歷史全都在本機上。因此,就算要進行歷史版本比對,也都是在本機進行,速度當然比需要即時連線的 VCS 來得快。
版本庫毀損的風險較低
同樣是基於分散式架構的緣故,Git 的版本庫會在各用戶端機器上存在多個完整的複本,因此就算伺服器上的版本庫損壞了,還是可以利用其他用戶端機器的複本輕易復原,大幅降低版本庫備份的成本和檔案遺失的風險。
彈性的本地分支
在使用 Subversion 時,分支其實就是把檔案複製到另一個資料夾,然後在不同的分支(資料夾)之間切換。在試過 Subversion 的分支之後,我還是有怕怕的感覺,因而傾向盡量少用。因為我覺得自己有一天一定會不小心把分支和主線給弄混了,以至於出現版本錯亂的情形。
我還沒有實驗 Git 的分支功能,但從現有的一些技術文件看來,Git 分支的一個主要優點,就是它可以完全在本機進行。比如說,你可以在本機建立幾個實驗性質的分支,等到你覺得時機成熟了,便可以將特定分支推送至主機,分享給別人。或者,有些實驗失敗的分支,也可以直接在本機砍掉,而其他開發人員根本不知道曾經有這些分支。
其他優點
有關 Git 的優點,在 Why Git is Better than X 這篇文章裡面有更多詳細的比較。個人是覺得 Git 還有一個小地方比 Subversion 好:它的版本庫目錄結構。
當我從遠端 Subversion 伺服器 checkout 一個版本庫到本機時,在本機的工作目錄下,每一層子目錄都會有一個 .svn 的資料夾,作為版本控制之用。Git 不是這樣。當我從遠端伺服器 clone 一個 Git 版本庫到本機時,就只有該版本庫複本的根目錄底下會有一個 .git 目錄,其他子目錄則很「乾淨」。此外,它的檔案忽略清單只要由 .git 目錄下的一個名為 .gitignore 的檔案就能完全控制。雖然是不太起眼的差異,我卻覺得蠻好的。大概是有點潔癖的緣故吧 XD
記得剛開始用 Subversion 時,它在 Windows 平台上的工具也還不是那麼方便,光是安裝就要手動設定一堆東西。現在,Subversion 伺服器已經幾乎是點下一步、下一步的方式就能安裝完成了,非常方便。而且,現有的軟體專案、寫作等工作,也都在是用 Subversion 來管理版本。在已經投資不少學習成本、且用得很習慣的情況下,要換另外一套版本管理系統總是會有一些阻力。
更順暢的工作流程
其實我 lag 很久了。沒有改用 Git,主要就是因為習慣問題,以及考慮到已經付出的學習成本,和沒有一個讓我覺得非換不可的理由。但是最近由於經常使用筆電,而且網路經常碰到無法連線的狀態(有時候是筆電所在的環境無法連網,有時候是伺服器離線),以至於有些本機的修改成果無法立即 commit 成一個修訂版次。這個時候,如果我還要繼續修改別的東西(例如修正另一個 bug),往往就會跟剛才的修改混在一起 commit,而且是要等到可連上網路時才能 commit。這樣的時間差,很容易造成一些遺漏或混亂,無形中就增加了成本和風險。我希望就算無法連接伺服器,還是能夠依目前的進度先 commit,並且繼續做後續的修改,這樣我就不用在那裡空等,也不用擔心自己等到網路可連線時,已經忘記那些檔案的 commit 先後次序。Git 可以做到這點。
快速
Git 之所以反應迅速,主要是因為分散式架構的緣故。在此架構下,版本庫的完整歷史全都在本機上。因此,就算要進行歷史版本比對,也都是在本機進行,速度當然比需要即時連線的 VCS 來得快。
版本庫毀損的風險較低
同樣是基於分散式架構的緣故,Git 的版本庫會在各用戶端機器上存在多個完整的複本,因此就算伺服器上的版本庫損壞了,還是可以利用其他用戶端機器的複本輕易復原,大幅降低版本庫備份的成本和檔案遺失的風險。
彈性的本地分支
在使用 Subversion 時,分支其實就是把檔案複製到另一個資料夾,然後在不同的分支(資料夾)之間切換。在試過 Subversion 的分支之後,我還是有怕怕的感覺,因而傾向盡量少用。因為我覺得自己有一天一定會不小心把分支和主線給弄混了,以至於出現版本錯亂的情形。
我還沒有實驗 Git 的分支功能,但從現有的一些技術文件看來,Git 分支的一個主要優點,就是它可以完全在本機進行。比如說,你可以在本機建立幾個實驗性質的分支,等到你覺得時機成熟了,便可以將特定分支推送至主機,分享給別人。或者,有些實驗失敗的分支,也可以直接在本機砍掉,而其他開發人員根本不知道曾經有這些分支。
其他優點
有關 Git 的優點,在 Why Git is Better than X 這篇文章裡面有更多詳細的比較。個人是覺得 Git 還有一個小地方比 Subversion 好:它的版本庫目錄結構。
當我從遠端 Subversion 伺服器 checkout 一個版本庫到本機時,在本機的工作目錄下,每一層子目錄都會有一個 .svn 的資料夾,作為版本控制之用。Git 不是這樣。當我從遠端伺服器 clone 一個 Git 版本庫到本機時,就只有該版本庫複本的根目錄底下會有一個 .git 目錄,其他子目錄則很「乾淨」。此外,它的檔案忽略清單只要由 .git 目錄下的一個名為 .gitignore 的檔案就能完全控制。雖然是不太起眼的差異,我卻覺得蠻好的。大概是有點潔癖的緣故吧 XD
很能同意您的感受 ^^
回覆刪除SVN最討厭的地方就是目錄底下到處都有.SVN的痕跡 ~_~ 亂奇怪的,而且不能隨時隨地commit也是個缺點,看了您的文章後又更深入了解一些些了。也正嘗試的轉換到git ... 如果有更方便的安裝方式會更好 XD ...
原來也有人跟我一樣對那些散在各處的 .svn 資料夾感冒啊 ^_^
回覆刪除Server 裝好之後,平常的操作就簡單多了。我是先用 Git Bash 練習下指令,等到差不多時,可能就改用 TortoiseGit 了,這個用戶端工具還蠻方便的,大概是之前用慣了 TortoiseSvn 的緣故吧。
當初在選擇版本控制的軟體時,就是在SVN跟GIT間考慮,不過SVN在WIN上面的支援度好像比較好一些些,也也專門的公司為他開發軟體,只要下一步就可以順利裝好了,而且TortoiseSvn也很簡單易用,所以就先選用SVN。不過看了許多的文章對於兩者的比較,其實對於GIT也很心動,基本上SVN也沒啥不好,就是那個.SVN目錄與無法本地端Commit,但它的好處就是有中央控管;當初沒有選用GIT的原因就是不知道它怎樣做commit到統一的儲存SERVER中,看了您的文章後就豁然開朗了,真是感謝! ^_^
回覆刪除很高興有幫助 ^_^
回覆刪除對於.svn 資料夾到處都是的問題,以前我也覺得這樣很麻煩,不過 TortoiseSVN 1.7 以後已經改掉這個問題了,如果還有卡在 svn 上頭的專案,可以考慮安裝最新版的 svn client.
回覆刪除git 有 fsck,
回覆刪除在 VirtualBox 當機後,
調用檢查後發覺 repository 損壞了,
起碼可以即時知道,用另部機的repository 去回復
SVN, 就完了
可以請教一下問題嗎?
回覆刪除我目前是git的新手
在Server與client有安裝好git,
client端連立好資料夾並git init完成,
那我現在想把我client端的資料夾送到server端該如何做到呢?
又或者將Server端的資料夾複製到client端,又該如何做呢?
我有下這指令,但一直告訴我密碼輸入錯誤:
git remote add origin git@192.168.0.53:honix-git.git
Hi Cherry,
回覆刪除有看過這個教學嗎:
http://gitimmersion-apputu.rhcloud.com/lab_01.html
另外:
http://huan-lin.blogspot.tw/2011/05/git-basic-workflow.html
希望有些幫助。