SVN中使用Git方法跟蹤指導
本節接著上節繼續介紹SVN中使用Git問題，上節我們講到了初始化代碼庫，初始化代碼庫以后就可以工作了，下面我們來看一下SVN中使用Git的開發流程，具體介紹如下。
開發流程
可以開始工作了。用git后開始養成一個新習慣，就是工作前先創建新分支:gitcheckout-b
new_branch-b后是分支名，創建的同時，你要轉到了新分支上。盡量保持master上沒有未提交到svn的commit，這樣隨時都可以很容易的產生一個干凈的分支。
接下來你可以寫代碼，修改文件或者添加文件。如果想看看修改了什么，可以用：gitdiff
如果對某個修改不滿意，希望恢復原狀，可以使用:
gitcheckoutpath/
filename相當于svnrevert
git引入一個索引(index)的概念，提交前，需要把要提交的文件加入到git索引(index)中：
gitaddpath/
filename1
gitaddpath/
filename2...然后提交
gitcommit-m"提交感言"
每次commit都是提交索引(index)中的內容。
如果要一次提交所有修改過的文件，可以一次性添加，然后提交
gitadd.
gitcommit-m"提交感言"
SVN中使用Git過程中如果只是修改，并沒有添加新文件，可以直接用下面的命令:gitcommit-a-m"提交感言"將被修改文件加入索引并提交，一次完成全過程。
在修改加入所索引后，如果想看看索引內容中都所了什么修改，可以用：
gitdiff
--cached
適合在提交前做***的codereview。
查看最近一次提交的內容，可以使用gitshow修改中隨時查看當前代碼庫的狀態：
gitstatus相當于svnstatus
刪除和移動某個文件：
gitrm
file
gitmv
file
newfile提交到svn，在完成了幾輪工作后，要將本地內容提交到遠程svn中，可以先讓當前分支和遠程svn同步：gitsvn
rebase然后將所有已經合并到master分支的本地修改提交到svn
gitsvn
dcommit如果在gitsvnrebase時發生代碼沖突，需要先手動解決沖突，然后用gitadd將修改加入索引，然后繼續rebase
gitsvn
rebase--continue
缺點
***說說SVN中使用Git中這種工作方式的缺點。這個話題稍微復雜一點。
svn和git的工作原理畢竟不同，git對代碼提交的非線性特性在svn中難以再現，如果使用了git-merge或者git-pull，再提交到svn，相關分支上的提交歷史有可能無法體現在svn上。從svn的使用者的角度，無法辨別這是一個提交還是一次合并，所以在和svn協作過程中，盡量不要使用merge，或者說，盡量讓代碼庫保持線性。
我的經驗是，如果不在乎svn中是否反映出提交歷史，使用merge也無妨。比如完成工作后，可以將工作分支合并到主分支中去：
gitcheckoutmaster
gitmergenew_branch先用checkout命令切換回master分支，然后將新分支中內容合并進來。然后在master分支上做gitsvnrebase和dcommit。從svn來看，這就是一個commit，new_branch上的提交歷史在svn上體現不出來。(有例外情況，以后再討論)。
還有一個解決辦法是盡量保持git代碼庫的線性特征。比如在new_branch分支中，先和master做rebase，再合并到master分支中：
gitrebasemaster
gitcheckoutmaster
gitmergenew_branch然后在master上做dcommit，就可以在svn代碼庫中看到完整的提交歷史。如果看到這已經有點頭暈了，可以干脆不管它，就按照前面的做法，直接在你的工作分支里dcommit，等對非線性開發有一定了解再來看各種情況。本節講解SVN中使用Git問題完畢，請關注本節其他相關報道。
【編輯推薦】
