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问题完毕,请关注本节其他相关报道。
【编辑推荐】
- SVN中使用Git简明介绍
- Git-SVN配合使用之简明教程
- 深度剖析:Subversion服务器安装配置
- MyEclipse中SVN安装配置新手指南
- Http访问SVN服务器的配置方法专家指导