如何在svn系統中使用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 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，等對非線性開發有一定了解再來看各種情況。
好了，基本上知道這些就可以干活了。
RFID管理系統集成商 RFID中間件 條碼系統中間層 物聯網軟件集成