利用Subversion兼容Git使用

利用Subversion兼容Git使用

 

若是正在使用svn，打算換到git，又暫時不想放棄已有的svn代碼庫，能夠選擇git- svn。說一說我本身從svn到git的經驗吧。

 

開始

安裝最新版本的git，從git 1.5.3之後支持git-svn，git和svn的配合就要藉助這個功能。

安裝完畢後要作一些簡單的配置。最直接的作法就是建立修改~/.gitconfig。下面是個人.gitconfig

[user]
        name = Robin Lu
        email = ---@gmail.com
[color]
        diff = auto
        status = auto
        branch = auto
[alias]
  st = status
  rb = svn rebase
  ci = commit -a
  co = checkout

[user]部分標示出使用者的身份，你提交的代碼會自動引用這一身份信息。[color]設置命令輸出的顏色。[alias]部分能夠簡化一些常 用命令，好比在這裏將git status簡化爲git st。

初始化代碼庫

首先用git-svn來初始化本地的代碼庫(repository)

git svn clone -s svn-repository-url

svn-repository-url部分使用svn代碼庫的url。若是要從trunk目錄或者某個branch目錄裏check out，要把-s換成-T、-b等選項。具體參看man git-svn。這個命令時間比較長，由於須要同步全部的提交歷史，還好只此一次，之後不會這麼慢了。作完這一步，在本地就有了一個完整的代碼庫，包括所 有commit的歷史和log，已經能夠開始用它來進行開發工做了。

不過，在開始開發以前，最好先作一次垃圾蒐集：

git gc

它對代碼庫的信息進行垃圾蒐集和壓縮，最明顯的做用就是減少磁盤佔用空間。第一次作效果尤爲明顯。

你能夠檢查一下代碼庫的狀態：

git status

如今應該在一個叫」master」的分支(branch)上。

用這個命令來顯示出全部的分支(branch):

git branch -a

master前有一個*號，表明你如今所處的分支，另外還有一個分支叫trunk，它是一個遠程分支(remote branch)，對應的是遠程svn代碼庫。master其實是trunk的一個本地分支。

接下來，須要配置忽略文件，讓git忽略一些目錄中不但願加入代碼庫的文件，相似svn propset svn:ignore。全局有效的忽略文件列表能夠添加在./.git/info/exclude文件中。好比我須要忽略全部vi產生的swp文件：

.*.swp

對於和目錄有關的忽略文件設置能夠在該目錄下建立.gitignore，而後加入須要忽略的內容，好比我但願忽略根目錄下的log,tmp等目錄， 能夠直接在根目錄下的.gitignore中加入:

log
tmp

開發流程

能夠開始工做了。用git後開始養成一個新習慣，就是工做前先建立新分支:

git checkout -b new_branch

-b後是分支名，建立的同時，你要轉到了新分支上。儘可能保持master上沒有未提交到svn的commit，這樣隨時均可以很容易的產生一個乾淨 的分支。

接下來你能夠寫代碼，修改文件或者添加文件。若是想看看修改了什麼，能夠用：

git diff

若是對某個修改不滿意，但願恢復原狀，可使用:

git checkout path/filename

至關於svn revert

git引入一個索引(index)的概念，提交前，須要把要提交的文件加入到git索引(index)中：

git add path/filename1
git add path/filename2
...

而後提交

git commit -m "提交感言"

每次commit都是提交索引(index)中的內容。

若是要一次提交全部修改過的文件，能夠一次性添加，而後提交

git add .
git commit -m "提交感言"

若是隻是修改，並無添加新文件，能夠直接用下面的命令:

git commit -a -m "提交感言"

將被修改文件加入索引並提交，一次完成全過程。

在修改加入所索引後，若是想看看索引內容中都所了什麼修改，能夠用：

git diff --cached

適合在提交前作最後的code review。

查看最近一次提交的內容，可使用

git show

修改中隨時查看當前代碼庫的狀態：

git status

至關於svn status

刪除和移動某個文件：

git rm file
git mv file newfile

提交到svn

在完成了幾輪工做後，要將本地內容提交到遠程svn中，能夠先讓當前分支和遠程svn同步：

git svn rebase

而後將全部已經合併到master分支的本地修改提交到svn

git svn dcommit

若是在git svn rebase時發生代碼衝突，須要先手動解決衝突，而後用git add將修改加入索引，而後繼續rebase

git svn rebase --continue

缺點

最後說說這種工做方式的缺點。這個話題稍微複雜一點。

svn和git的工做原理畢竟不一樣，git對代碼提交的非線性特性在svn中難以再現，若是使用了git-merge或者git-pull，再提交 到svn，相關分支上的提交歷史有可能沒法體如今svn上。從svn的使用者的角度，沒法辨別這是一個提交仍是一次合併，因此在和svn協做過程當中，儘可能 不要使用merge，或者說，儘可能讓代碼庫保持線性。

個人經驗是，若是不在意svn中是否反映出提交歷史，使用merge也無妨。好比完成工做後，能夠將工做分支合併到主分支中去：

git checkout master
git merge new_branch

先用checkout命令切換回master分支，而後將新分支中內容合併進來。而後在master分支上作git svn rebase和dcommit。從svn來看，這就是一個commit，new_branch上的提交歷史在svn上體現不出來。(有例外狀況，之後再討 論)。

還有一個解決辦法是儘可能保持git代碼庫的線性特徵。好比在new_branch分支中，先和master作rebase，再合併到master分 支中：

git rebase master
git checkout master
git merge new_branch

而後在master上作dcommit，就能夠在svn代碼庫中看到完整的提交歷史。

若是看到這已經有點頭暈了，能夠乾脆無論它，就按照前面的作法，直接在你的工做分支裏dcommit，等對非線性開發有必定了解再來看各類狀況。

好了，基本上知道這些就能夠幹活了。