git-svn:通过 git 管理 svn 代码
简介
svn和git都是常用的版本管理软件,但是git无论在理念或是功能上都比svn更为先进。但是有的公司是以svn作为*仓库,这时git与svn代码的同步就可以通过 git-svn这个软件进行,从而用git管理svn代码。最后的效果相当于把svn仓库当作git的一个remote(远程仓库),而你本地的代码都是通过git来管理,只有push到svn时才会把你本地的commit同步到svn。
从svn克隆
首先看一看用于测试的svn项目结构,svn的仓库路径是file:///d/Projects/svn_repo
,可以用svnadmin create svn_repo
命令新建。该仓库有2个分支,1个tag,属于svn标准布局。
SVN项目结构:
1
|
/d/proj1
|
命令格式:git svn clone <svn仓库路径> [本地文件夹名] [其他参数]
相当于git clone
示例: git svn clone file:///d/Projects/svn_repo proj1_git -s --prefix=svn/
参数说明:
-
-s
告诉 Git 该 Subversion 仓库遵循了基本的分支和标签命名法则,也就是标准布局。
如果你的主干(trunk,相当于非分布式版本控制里的master分支,代表开发的主线),分支(branches)或者标签(tags)以不同的方式命名,则应做出相应改变。-s
参数其实是-T trunk -b branches -t tags
的缩写,这些参数告诉git这些文件夹与git分支、tag、master的对应关系。 -
--prefix=svn/
给svn的所有remote名称增加了一个前缀svn,这样比较统一,而且可以防止warning: refname 'xxx' is ambiguous.
现在,看下用git-svn克隆的项目情况(运行git branch -a),此处git的分支情况是与svn文件夹对应的。
1
|
* master
|
只下载指定版本之后的历史
如果svn上的commit次数非常多, git svn clone 就会非常慢,一般超过几百个版本就要大概十分钟。此时可以在clone的时候只下载部分版本,
命令:git svn clone -r<开始版本号>:<结束版本号> <svn项目地址> [其他参数]
示例:git svn clone -r2:HEAD file:///d/Projects/svn_repo proj1_git -s
说明:其中2为svn版本号,HEAD代表最新版本号,就是只下载svn服务器上版本2到最新的版本的代码.
工作流程
简单来说就是,首次新建分支会记录和svn远程对应分支的追踪关系,之后你的所有commit都是在本地的;并且和纯git管理的项目没有区别,只是在git svn rebase
和git svn dcommit
的时候才会和svn仓库发生关系
一般工作流程(推荐)
- 新建分支
git checkout -b <本地分支名称> <远程分支名称>
示例:git checkout -b a svn/a
说明:此处新建了一个本地分支a,与svn的a分支对应。 - 在本地工作,commit到对应分支上
-
git svn rebase
从svn上更新代码, 相当于svn的update。 -
git svn dcommit
提交你的commit到svn远程仓库,建议提交前都先运行下git svn rebase。
在git本地其他分支工作的情况
-
git chechout -b a svn/a
此处新建了一个本地分支a,与svn的a分支对应。 -
git checkout -b feature1
在a分支的基础上,开一个本地feture1分支 - 在feture1分支进行开发,有了多次commit
- 在feture1分支上进行
git svn rebase
和git svn dcommit
,这样feature1的commit也会提交到svn的a分支上。
需要注意的是要记住feture1是从哪个分支checkout的,它的svn远程分支就与哪个相同。比如此处是a分支,那么svn分支就是svn/a,commit就会提交到svn的a分支。
SVN分支管理
新建分支到svn
命令:git svn branch <分支名称>
示例:git svn branch c_by_git
说明:在svn仓库上建了了一个c_by_git分支
分支情况
1
|
a
|
删除svn分支
- 删除svn分支目录
svn rm <svn分支路径> -m <commit信息>
示例:svn rm file:///d/Projects/svn_repo/branches/c_by_git -m 'rm branch'
- 删除远程跟踪分支
git branch -D -r <远程分支名称>
示例:git branch -D -r svn/c_by_git
SVN上tag管理
新建tag
命令:git svn tag <tag名称>
示例:git svn tag v1.1
说明:在svn仓库上建了一个v1.1tag
删除tag
-
删除svn目录
svn rm <svntag路径> -m <commit信息>
示例:svn rm file:///d/Projects/svn_repo/tags/v1.1 -m 'rm tag'
-
删除远程跟踪分支
git branch -D -r <远程分支名称>
示例:git branch -D -r svn/tags/v1.1
说明:svn的tag和分支在git看来是一样的,所以此处还是用的git branch
冲突解决
如果本地和svn都进行了修改,则不能快速前进,git svn rebase 会出现错误。
这时应该按以下步骤操作:
-
手动修改冲突文件,修改完成后
git add
-
git rebase --continue
-
git svn dcommit
svn不遵循规范的情况
以上讲的都是svn仓库是标准的情况,如果不标准,则以下几个地方都会有所不同。主要就是每个步骤基本都要添加svn的具体路径。
先看看,示例项目的结构,仓库路径是file:///d/Projects/svn_repo2
。这个项目主分支是dev文件夹,branch1和tag1文件夹分别代表的是一个分支和tag。
svn项目结构:
1
|
/d/proj2
|
从svn克隆
命令:git svn clone <svn项目地址,要包含具体分支路径> [本地文件夹名]
示例:git svn clone file:///d/Projects/svn_repo2/dev proj2_svn
添加远程分支信息
命令:
git config --add svn-remote.<远程分支名称>.url <svn地址,要包含具体分支路径>
git config --add svn-remote.<远程分支名称>.fetch :refs/remotes/<远程分支名称>
示例:
git config --add svn-remote.svn/branch1.url file:///d/Projects/svn_repo2/branch1
git config --add svn-remote.svn/branch1.fetch :refs/remotes/svn/branch1
说明:此处的“远程分支名称”可以随意填写,只要这三个保持一致即可。建议都给他们增加svn/
前缀,这样svn的所有分支显示起来会比较一致,与上面clone时的--prefix=svn/
类似。
新建本地分支,与svn对应
命令:
-
git svn fetch <远程分支名称>
获取svn仓库该分支的代码 git checkout -b <本地分支名> <远程分支名称>
示例:
git svn fetch svn/branch1
git checkout -b branch1 svn/branch1
分支情况:
1
|
* branch1
|
下一篇: 一个完整的 Git 拉取代码实例
推荐阅读
-
像首席技术官一样思考:如何高效管理 30 人的研发团队?-管理越多越轻松。好的研发团队,应该是上拨下用,即下级对上级的向上管理;而不是反过来,总是向下管理,甚至是 CTO 做经理的事,经理做工程师的事,工程师最终会被当成实习生。如果是这样,就会越管越累,不仅团队无法成长,而且团队整天很忙还效率低下,问题一大堆。 有这样一个小故事:一位高级经理下班后帮忙倒垃圾,结果被老板训斥了一顿。这就好比首席技术官做了实习生自己该做的事。事情本身没有对错之分,只是从不同的角度有不同的理解。 古人云:"用人不疑,疑人不用"。在面对自己的研发团队时,应该相信他们能做好,授权一线开发人员充分发挥专业特长,不要限制他们的工作。但在相信他们的同时,也要进行二次确认,始终秉持 "我相信,但我要确认 "的原则和严谨的精神。因为每个人都会犯错和疏忽,通过发挥团队的智慧,团队犯错的机会就会大大减少。比如回归测试、代码审查、开发演示、变更审批等等。 如前所述,每个人都难免会犯错。但作为管理者,你所设计和商定的流程不能出错。管理者的每一个决定和沟通都应该经过深思熟虑。就像红绿灯的交通设计,某辆车不小心闯红灯可能会扣分,但红绿灯的设计一定要正确、人性化、统一。再比如,开发人员可能会因为疏忽大意写出 bug,但研发流程的设计和上线流程的发布不能有任何差错。因此,流程体系的设计,一方面要结合当前团队规模、业务特点和需要重点解决的问题来设计,另一方面也要在人员防错、效率提升、发挥团队集体智慧等维度进行综合考量。应该站在更高更抽象的角度去思考,不断思考一个倍受欢迎的园区应该如何设计,思考一个灵动、经典、永恒的建筑应该遵循怎样的模式,思考一个成功、优秀、卓越的研发团队应该需要怎样的流程和制度。 最后,反馈很重要。向上汇报很重要,向下反馈也很重要。能够保持顺畅的双向反馈和闭环管理,对研发团队的协作和沟通有着非常明显的积极作用。在向上汇报方面,要培养团队在正式汇报、会议汇报、私下沟通、书面总结、非正式场合等方面的沟通能力,提醒下属报喜也要报忧。凡事先记录,再跟进,最后反馈。反馈很重要,主动汇报更难得。 另一方面,同时也不要忽视向下反馈。好的爱,是双向的。团队也是如此,没有严格的上下级之分,只是分工和角色不同而已。作为管理者,不必总保持一种 "神秘感",让人 "捉摸不透 "才是牛。当团队做得好或有人做得好时,要记得在公开或私下场合给予肯定和赞许。业务有增长、业绩有提升时,别忘了给团队一些鼓励,或者安排一次下午茶或聚餐。在例会或正式会议上,也可以同步向大家传达一些重要信息和高层指示。"欲速则不达,欲远则同行"。 当向上汇报、向下反馈的沟通闭环形成后,同时结合前面研发过程的管理闭环,双管齐下,就能形成良性循环。如此反复,持之以恒,优秀卓越的研发团队,必将呈现。 能力、产出和效率 接下来,继续重复关于能力、产出和效率的话题。 站在不同的角色,以及一个企业经营、生存和发展所需要的基础上,我把研发生产力分为三个层次,分别是:一线员工关心的研发能力、管理层关心的软件产出和操作人员关心的企业生产效率。简单概括就是:既要把工作做好,又要能出成果,还要能帮企业赚钱。
-
IOS UI 自动化测试实践:pyhton-wda 环境设置篇-Xcode 版本:10.1iphone 版本:12.0.1OS 版本:10.13.6 实践开始 创建一个新目录并从 git 下载 WDA 项目代码。 git clone https://github.com/facebook/WebDriverAgent 并运行初始化脚本。 ./Scripts/bootstrap.sh 出现以下错误信息:原因:Carthage 需要下载相关的依赖项,而这些依赖项并未在本地安装。 解决方法通过 brew 下载并安装依赖项: brew install carthage 下载成功并初始化脚本后,出现以下错误:原因:需要 npm 来打包响应 js 文件,而机器上未安装该文件。 解决方案:通过 brew 下载并安装 npm(注:brew 真的是个好东西):brew install npm 安装成功后,继续初始化脚本。/Scripts/bootstrap.sh Xcode 相关操作
-
项目管理] git 和代码云的使用 【重复
-
在本地通过 git 拉取项目代码
-
git-svn:通过 git 管理 svn 代码
-
如何配置 Git 的 ssh 方法,如何通过 ssh 方法拉取和提交代码
-
通过 STS 或 Eclipse 解决从 Git 平台向本地调用代码后代码凌乱的问题。
-
git:添加项目成员以管理代码、克隆代码、配置 ssh 公钥
-
GIT 通过 Gerrit ID 拉取已提交但未纳入的代码如何?
-
GIT 代码管理:git 远程添加