还剩23页未读，继续阅读
本资源只提供10页预览，全部文档请下载后查看！喜欢就下载吧，查找使用更方便
文本内容:
详解之八与其他系统Git Gitgit svn•初始设定•入门•提交至I」Subversion•拉取最新进展•Git分支问题•Subversion分支•切换当前分支•又寸应Subversion的命令•Git-Svn总结•导入•Subversion•Perforce•自定导入脚本•Git与其他系统世界不是完美的大多数时候，将所有接触到的项目全部转向Git是不可能的有时我们不得不为某个项目使用其他的版本控制系统VCS,Version ControlSystem,其中比较常见的是Subversion你将在本章的第一部分学习使用git svnGit为Subversionz附带的双向桥接工具习惯了Git的工作流程以后，你可能会创建一些特性分支，完成相关的开发工作，然后合并他们如果要用git svn向Subversion推送内容，那么最好是每次用衍合来并入一个单一分支，而不是直接合并使用衍合的原因是Subversion只有一个线性的历史而不像Git那样处理合并，所以Git svn在把快照转换为Subversion的commit时只能包含第一个祖先假设分支历史如下创建一个experiment分支，进行两次提交，然后合并到master在dcommit的时候会得到如下输出$git svndcommit Committingto file:///tmp/test-svn/trunk...M CHANGES,txtCommitted r85M CHANGES,txt r85=4bfebeec434dl56c36f2bcdl8f4e3d97dc3269a2trunkNo changesbetween currentHEAD and refs/remotes/trunk Resettingto thelatestrefs/remotes/trunk COPYING,txt:locally modifiedINSTALL,txt:locally modifiedMCOPYING.txt M INSTALL,txt Committedr86MINSTALL.txt MCOPYING,txt r86=2647f6b86ccfcaad4ec58c520e369ec81f7c283c trunkNo changesbetween currentHEADand refs/remotes/trunk Resettingto the19fast rafs/ramctds/trunk在一个包含了合并历史的分支上使用dcommit可以成功运行不过在Git项目的历史中,它没有重写你在experiment分支中的两个commit另一方面，这些改变却出现在了SVN版本中同一个合并commit中在别人克隆该项目的时候，只能看到这个合并commit包含了所有发生过的修改；他们无法获知修改的作者和时间等提交信息Subversion分支Subversion的分支和Git中的不尽相同；避免过多的使用可能是最好方案不过，用git svn创建和提交不同的Subversion分支仍是可行的创建新的SVN分支要在Subversion中建立一个新分支，需要运行git svn branch[分支名]To createa newbranchin Subversion,you rungit svnbranch[branchname]:$git svnbranch operaCopying file:///tmp/test-svn/trunk atr87tofile:///tmp/test-svn/branches/opera...Found possiblebranch point:file:///tmp/test-svn/trunk=〉\file:///tmp/test-svn/branches/opera,87Foundbranch parent:operalf6bfe471083cbca06ac8d4176f7ad4de0d62e5f Following parent with do_switchSuccessfully followedparent r89二9b6fe0b90c5c9adf9165f700897518dbc54a7cbfopera相当于在Subversion中的svn copytrunk branches/opera命令并且对Subversion服务器进行了相关操作值得提醒的是它没有检出和转换到那个分支；如果现在进行提交，将提交到服务器上的trunk,而非opera切换当前分支Git通过搜寻提交历史中Subversion分支的头部来决定dcommit的目的地--------------而它应该只有一个，那就是当前分支历史中最近一次包含git-svn-id的提交如果需要同时在多个分支上提交，可以通过导入Subversion上某个其他分支的commit来建立以该分支为dcommit目的地的本地分支比如你想拥有一个并行维护的opera分支，可以运行$git branchopera remotes/opera然后，如果要把opera分支并入trunk（本地的master分支），可以使用普通的gitmerge不过最好提供一条描述提交的信息（通过-m）,否则这次合并的记录是Merge branchoopera,而不是任何有用的东西记住，虽然使用了git merge来进行这次操作，并且合并过程可能比使用Subversion简单一些（因为Git会自动找到适合的合并基础），这并不是一次普通的Git合并提交最终它将被推送回commit无法包含多个祖先的Subversion服务器上;因而在推送之后,它将变成一个包含了所有在其他分支上做出的改变的单一commit把一个分支合并到另一个分支以后，你没法像在Git中那样轻易的回到那个分支上继续工作提交时运行的dcommit命令擦除了全部有关哪个分支被并入的信息，因而以后的合并基础计算将是不正确的dcommit让git merge的结果变得类似于git merge—squash不幸的o是，我们没有什么好办法来避免该情况——Subversion无法储存这个信息，所以在使用它作为服务器的时候你将永远为这个缺陷所困为了不出现这种问题，在把本地分支（本例中的opera）并入trunk以后应该立即将其删除对应Subversion的命令git svn工具集合了若干个与Subversion类似的功能，对应的命令可以简化向Git的转化过程下面这些命令能实现Subversion的这些功能SVN风格的历史习惯了Subversion的人可能想以SVN的风格显示历史，运行git svn log可以让提交历史显示为SVN格式$git svn logr87|schacon2009-05-0216:07:37-0700Sat,02May2009|2lines autogenchange——r86|schacon2009-05-0216:00:21-0700Sat,02May2009|2lines Mergebranch experimentr85|schacon2009-05-0216:00:09-0700Sat,02May2009|2linesupdated thechangelog关于git svnlog,有两点需要注意首先,它可以离线工作，不像svnlog命令,需要向Subversion服务器索取数据其次，它仅仅显示已经提交到Subversion服务器上的commit在本地尚未dcommit的Git数据不会出现在这里；其他人向Subversion服务器新提交的数据也不会显示等于说是显示了最近已知Subversion服务器上的状态SVN日志类似git svnlog对git log的模拟，svn annotate的等效命令是git svnblame［文件名］其输出如下$git svnblame README,txt2temporal Protocol Buffers-Googles datainterchangeformat2temporal Copyright2008Google Inc.2temporal.google,com/apis/protocolbuffers/2temporal22temporal C++Installation-Unix22temporal=======================2temporal79schacon Committingin git-svn.78schacon2temporal Tobuild andinstall theC++ProtocolBufferruntime andtheProtocol2temporal Buffercompiler protocexecute thefollowing:2temporal同样，它不显示本地的Git提交以及Subversion上后来更新的内容SVN服务器信息还可以使用git svn info来获取与运行svninfo类似的信息$git svninfo Path:.URL:.googlecode.com/svn/trunk RepositoryRoot:.googlecode.com/svn RepositoryUU1D:4c93b258-373f-llde-be05-5f7a86268029Revision:87Node Kind:directory Schedule:normal Last Changed Author:schacon LastChanged Rev:87LastChangedDate:2009-05-0216:07:37-0700Sat,02May2009它与blame和log的相同点在于离线运行以及只更新到最后一次与Subversion服务器通信的状态略Subversion之所略假如克隆了一个包含了svn:ignore属性的Subversion仓库，就有必要建立对应的.gitignore文件来防止意外提交一些不应该提交的文件git svn有两个有益于改善该问题的命令第一个是git svncreate-ignore,它自动建立对应的.gitignore文件，以便下次提交的时候可以包含它第二个命令是git svnshow-ignore,它把需要放进.gitignore文件中的内容打印到标准输出，方便我们把输出重定向到项目的黑名单文件$git svnshow-ignore.git/info/exclude这样一来，避免了.gitignore对项目的干扰如果你是一个Subversion团队里唯一的Git用户，而其他队友不喜欢项目包含.gitignore,该方法是你的不二之选Git-Svn总结git svn工具集在当前不得不使用Subversion服务器或者开发环境要求使用Subversion服务器的时候格外有用不妨把它看成一个跛脚的Git,然而，你还是有可能在转换过程中碰到一些困惑你和合作者们的迷题为了避免麻烦，试着遵守如下守则保持一个不包含由git merge生成的commit的线性提交历史将在主线分支外进行的•开发通通衍合回主线；避免直接合并・不要单独建立和使用一个Git服务来搞合作可以为了加速新开发者的克隆进程建立一个，但是不要向它提供任何不包含git-svn-id条目的内容甚至可以添加一个pre-receive挂钩来在每一^N是交信息中查找git-svn-id并拒绝提交那些不包含它的commit如果遵循这些守则，在Subversion上工作还可以接受然而，如果能迁徙到真正的Git服务器，则能为团队带来更多好处
8.2迁移到Git如果在其他版本控制系统中保存了某项目的代码而后决定转而使用Git，那么该项目必须经历某种形式的迁移本节将介绍Git中包含的一些针对常见系统的导入脚本，并将展示编写自定义的导入脚本的方法导入你将学习到如何从专业重量级的版本控制系统中导入数据——Subversion和Perforce——因为据我所知这二者的用户是（向Git）转换的主要群体，而且Git为此二者附带了高质量的转换工具Subversion读过前一节有关git svn的内容以后，你应该能轻而易举的根据其中的指导来git svn clone一个仓库了；然后，停止Subversion的使用，向一个新Git server推送，并开始使用它想保留历史记录，所花的时间应该不过就是从Subversion服务器拉取数据的时间（可能要等上好一会就是了）然而，这样的导入并不完美；而且还要花那么多时间，不如干脆一次把它做对！首当其冲的任务是作者信息在Subversion,每个提交者在都在主机上有一个用户名，记录在提交信息中上节例子中多处显示了schacon,比如blame的输出以及git svnlog如果想让这条信息更o好的映射到Git作者数据里，则需要从Subversion用户名到Git作者的一个映射关系建立一个叫做user.txt的文件，用如下格式表示映射关系schacon=Scott Chaconschacon@geemail.com seise=Someo Nelseselse@geemail.com通过该命令可以获得SVN作者的列表$svnlog一一xml|grep author|sort-u perl-pes/・（・）〈/$1二/它•将输出XML格式的日志——你可以找到作者，建立一个单独的列表，然后从XML中抽取出需要的信息（显而易见，本方法要求主机上安装了grep,sort和perl.）然后把输出重定向到user.txt文件，然后就可以在每一项的后面添加相应的Git用户数据为git svn提供该文件可以然它更精确的映射作者数据你还可以在clone或者init后面添加一no-metadata来阻止git svn包含那些Subversion的附加信息这样import命令就变成了$git-svnclone.googlecode.com/svn/\一一authors-file=users.txt一一no-metadata_s my_project现在my_project目录下导入的Subversion应该比原来整洁多了原来的commit看上去是这样commit37efa680e8473b615de980fa935944215428a35a Author:schaconschacon@4c93b258-373f-llde-be05-5f7a86268029Date:Sun May300:12:222009+0000fixed install-go totrunk git-svn-id:.googlecode.com/svn/trunk@944c93b258-373f-llde-be05-5f7a86268029现在是这样commit03a8785f44c8ea5cdb0e8834b7c8e6c469be2ff2Author:Scott Chaconschacon@geemail.com Date:Sun May300:12:222009+0000fixed install-go totrunk不仅作者一项干净了不少，git-svn-id也就此消失了你还需要一点post-import（导入后）清理工作最起码的，应该清理一下git svn创建的那些怪异的索引结构首先要移动标签，把它们从奇怪的远程分支变成实际的标签,然后把剩下的分支移动到本地要把标签变成合适的Git标签，运行$cp-Rf.git/refs/remotes/tags/*.git/refs/tags/$rm-Rf.git/refs/remotes/tags该命令将原本以tag/开头的远程分支的索引变成真正的（轻巧的）标签接下来，把refs/remotes下面剩下的索引变成本地分支$cp-Rf.git/refs/remotesA.git/refs/heads/$rm-Rf.git/refs/remotes现在所有的旧分支都变成真正的Git分支，所有的旧标签也变成真正的Git标签最后一项工作就是把新建的Git服务器添加为远程服务器并且向它推送下面是新增远程服务器的例子$git remoteadd origingit@my-git-server:myrepository.git为了让所有的分支和标签都得到上传，我们使用这条命令$git pushorigin--all所有的分支和标签现在都应该整齐干净的躺在新的Git服务器里了Perforce你将了解到的下一个被导入的系统是Perforce.Git发行的时候同时也附带了一个Perforce导入脚本,不过它是包含在源码的contrib部分---------------------------而不像git svn那样默认可用运行它之前必须获取Git的源码，可以在下载$git clonegit://git.kernel,org/pub/scm/git/git.git$cdgit/contrib/fast-import在这个fast-import目录下，应该有一个叫做git-p4的Python可执行脚本主机上必须装有Python和p4工具该导入才能正常进行例如，你要从Perforce公共代码仓库（译注Perforce PublicDepot,Perforce官方提供的代码寄存服务）导入Jam工程为了设定客户端，我们要把P4P0RT环境变量export到Perforce仓库$export P4P0RT=public.perforce,com:1666运行git-p4clone命令将从Perforce服务器导入Jam项目，我们需要给出仓库和项目的路径以及导入的目标路径$git-p4clone//public/jam/src@all/opt/p4import Importingfrom//public/jam/src@al1into/opt/p4import Reinitializedexisting Git repository in/opt/p4import/.git/Import destination:refs/remotes/p4/master Importingrevision4409100%现在去/opt/p4import目录运行一下git log,就能看到导入的成果$git log-2commit lfd4ecl26171790efd2db83548b85blbbbc07dc2Author:Perforcestaff〈〉Date:Thu Aug1910:18:452004-0800Drop rc3moniker ofjam-
2.
5.Foldedrc2and rc3RELNOTES into the mainpart ofthe document.Built newtar/zip balls.Only16months later.[git-p4:depot-paths=^//public/jam/src/^:change=4409]commit ca8870db541a23ed867f38847eda65bf4363371d Author:Richard Geigerrnig@perforce.com Date:Tue Apr2220:51:342003-0800Update derivedjamgram,c[git-p4:depot-paths=，z//public/jam/src/zz:change=3108]每一个commit里都有一个git-p4标识符这个标识符可以保留，以防以后需要引用Perforce的修改版本号然而，如果想删除这些标识符，现在正是时候——在开启新仓库之前可以通过git filter-branch来批量删除这些标识符$git filter-branch--msg-filtersed-e〃/\[git-p4:/d〃Rewritelfd4ecl26171790efd2db83548b85blbbbc07dc2123/123RefJ refs/heads/master，was rewritten现在运行一下git log，你会发现这些commit的SHA-1校验值都发生了改变，而那些git-p4字串则从提交信息里消失了或许现在你已经在考虑将先前的项目转向Git本章的第二部分将介绍如何将项目迁移到Git:先介绍从Subversion的迁移，然后是Perforce,最后介绍如何使用自定义的脚本进行非标准的导入
8.1Git与Subversion当前，大多数开发中的开源项目以及大量的商业项目都使用Subversion来管理源码作为最流行的开源版本控制系统，Subversion已经存在了接近十年的时间它在许多方面与CVS十分类似，后者是前者出现之前代码控制世界的霸主Git最为重要的特性之一是名为git svn的Subversion双向桥接工具该工具把Git变成了Subversion服务的客户端，从而让你在本地享受到Git所有的功能,而后直接向Subversion服务器推送内容，仿佛在本地使用了Subversion客户端也就是说，在其他人忍受古董的同时，你可以在本地享受分支合并，使暂存区域，衍合以及单项挑拣等等这是个让Git偷偷潜入合作开发环境的好东西，在帮助你的开发同伴们提高效率的同时，它还能帮你劝说团队让整个项目框架转向对Git的支持这个Subversion之桥是通向分布式版本控制系统DVCS,Distributed VCS世界的神奇隧道git svnGit中所有Subversion桥接命令的基础是git svn所有的命令都从它开始相关的命令数o目不少，你将通过几个简单的工作流程了解到其中常见的一些值得警戒的是，在使用git svn的时候，你实际是在与Subversion交互，Git比它要高级复杂的多尽管可以在本地随意的进行分支和合并，最好还是通过衍合保持线性的提交历史，尽量避免类似与远程Git仓库动态交互这样的操作$git log-2commit10al6d60cffcal4d454al5c6164378f4082bc5b0Author:Perforcestaff support@perforce.com Date:Thu Aug1910:18:452004-0800Drop rc3,monikerof jam-
2.
5.Folded rc2and rc3RELNOTES into the mainpart ofthe document.Builtnew tar/zip balls.Only16months later,commit2b6c6db3nde176c34c66eclc40a49405e6b527b2Author:Richard Geigerrmg@perforce.com Date:Tue Apr2220:51:342003-0800Update derivedjamgram,c至此导入已经完成，可以开始向新的Git服务器推送了自定导入脚本如果先前的系统不是Subversion或Perforce之一，先上网找一下有没有与之对应的导入脚本——导入CVS,Clear Case,Visual SourceSafe,甚至存档目录的导入脚本已经存在假如这些工具都不适用，或者使用的工具很少见，抑或你需要导入过程具有更多可制定性则应该使用git fast-import该命令从标准输入读取简单的指令来写入具体的Git数据这样创建Git对象比运行纯Git命令或者手动写对象要简单的多（更多相关内容见第九章）通过它，o你可以编写一个导入脚本来从导入源读取必要的信息，同时在标准输出直接输出相关指示你可以运行该脚本并把它的输出管道连接到git fast-import下面演示一下如何编写一个简单的导入脚本假设你在进行一项工作，并且按时通过把工作目录复制为以时间戳back_YY_MM_DD命名的目录来进行备份，现在你需要把它们导入Git目录o结构如下$Is/opt/import_from back_2009_0102back_2009_0l_04back_2009_01_14back20090203current为了导入到一个Git目录，我们首先回顾一下Git储存数据的方式你可能还记得，Git本质上是一个commit对象的链表，每一个对象指向一个内容的快照而这里需要做的工作就是告诉fast-import内容快照的位置，什么样的commit数据指向它们，以及它们的顺序我们采取一次处理一个快照的策略，为每一个内容目录建立对应的commit,每一个commit与之前的建立链接正如在第七章Git执行策略一例一节中一样，我们将使用Ruby来编写这个脚本，因为它是我日常使用的语言而且阅读起来简单一些你可以用任何其他熟悉的语言来重写这个例子——它仅需要把必要的信息打印到标准输出而已同时，如果你在使用Windows,这意味着你要特别留意不要在换行的时候引入回车符译注carriage returns,Windows换行时加入的符号，通常说的\r——Git的fast-import对仅使用换行符LF而非Windows的回车符CRLF要求非常严格首先，进入目标目录并且找到所有子目录，每一个子目录将作为一个快照被导入为一个commit我们将依次进入每一个子目录并打印所需的命令来导出它们脚本的主循环大致是这样last_mark=nil#循环遍历所有目录Dir.chdir ARGV
[0]doDir.glob*.each dodir|next ifFile,filedir#进入目标目录Dir.chdirdirdo last_mark=print_export dir,last markend endend我们在每一个目录里运行print_export，它会取出上一个快照的索引和标记并返回本次快照的索引和标记；由此我们就可以正确的把二者连接起来标记mark是fast-import中对commit标识符的叫法；在创建commit的同时，我们逐一赋予一个标记以便以后在把它连接到其他commit时使用因此，在print_export方法中要做的第一件事就是根据目录名生成一个标记mark=convert_dir_to_markdir实现该函数的方法是建立一个目录的数组序列并使用数组的索引值作为标记，因为标记必须是一个整数这个方法大致是这样的$marks=[]def convert_dir_to_markdir if!$marks.include dir$marks dirend$marks.index dir+
1.to_s end有了整数来代表每个commit,我们现在需要提交附加信息中的日期由于日期是用目录名表示的，我们就从中解析出来print_export文件的下一行将是date=convert_dir_to date dir而convert_dir_to_date贝淀义为def convert_dir_to_datedirif dir==current5return Time.now.to_i elsedir=dir.gsub Cback_,year,month,day=dir.split C_return Time,localyear,month,day.to_i endend它为每个目录返回一个整型值提交附加信息里最后一项所需的是提交者数据，我们在一个全局变量中直接定义之$author=Scott Chacon schacon@example.coin〉我们差不多可以开始为导入脚本输出提交数据了第一项信息指明我们定义的是一个commit对象以及它所在的分支，随后是我们生成的标记，提交者信息以及提交备注，然后是前一个commit的索引，如果有的话代码大致这样#打印导入所需的信息puts Jcommit refs/heads/master，puts mark:+mark putscommitter#{$author}#{date}-0700〃export dataimported from+dir puts5from:+last_mark iflast_mark时区-0700处于简化目的使用硬编码如果是从其他版本控制系统导入，则必须以变量的形式指明时区提交备注必须以特定格式给出data size\ncontents该格式包含了单词data,所读取数据的大小，一个换行符，最后是数据本身由于随后指明文件内容的时候要用到相同的格式，我们写一个辅助方法，export_data:def export_datastring printdata#{string,size}\n#{stringend唯一剩下的就是每一个快照的内容了这简单的很，因为它们分别处于一个目录——你可以输出deleeall命令，随后是目录中每个文件的内容Git会正确的记录每一个快照:puts,deleteair Dir.glob**/*.each do|file|nextif!File.filefile iniine_datafile end注意由于很多系统把每次修订看作一个commit到另一个commit的变化量，fast-import也可以依据每次提交获取一个命令来指出哪些文件被添加，删除或者修改过,以及修改的内容我们将需要计算快照之间的差别并且仅仅给出这项数据，不过该做法要复杂很多——还如不直接把所有数据丢给Git然它自己搞清楚假如前面这个方法更适用于你的数据，参考fast-import的man帮助页面来了解如何以这种方式提供数据列举新文件内容或者指明带有新内容的已修改文件的格式如下M644inline path/to/file datasize filecontents这里，644是权限模式加入有可执行文件，则需要探测之并设定为755，而inline说明我们在本行结束之后立即列出文件的内容我们的inline_data方法大致是def iniine_datafile,code=M,mode=644,content=File,readfileputs”#{code}#{mode}inline exportdatacontentend我们重用了前面定义过的export_data,因为这里和指明提交注释的格式如出一辙最后一项工作是返回当前的标记以便下次循环的使用return mark注意如果你在用Windows,一定记得添加一项额外的步骤前面提过，Windows使用CRLF作为换行字符而Git fast-import只接受LF为了绕开这个问题来满足gitOfa st-import，你需要让ruby用LF取代CRLF:Sstdout.binmode搞定了现在运行该脚本，你将得到如下内容$ruby import,rb/opt/import_from commitrefs/heads/master mark:1committer ScottChaconschacon@geemail.com1230883200-0700data29imported fromback_2009_0l_02deleteal1M644inline file.rb data12version twocommitrefs/heads/master mark:2committer Scott Chaconschacon@geemai
1.com1231056000-0700data29imported fromback_2009_0l_04from:1deleteall M644inline file,rb data14version threeM644inline new.rb data16new versionone...要运行导入脚本，在需要导入的目录把该内容用管道定向到git fast-import你可以建立一0个空目录然后运行git init作为开头，然后运行该脚本$git initInitialized emptyGitrepository in/opt/import_to/.git/$ruby import.rb/opt/import_from gitfast-import git-fast-import-Alloc5d objects:5000Total objects:181duplicatesblobs:71duplicates0deltas trees:60duplicates1deltas commits:50duplicates0deltas tags:00duplicates0deltas Totalbranches:11loadsmarks:10245unique atoms:3Memory total:2255KiB pools:2098KiB objects:156KiB-pack_report:getpagesize二4096pack_report:core.packedGitWindowSize=33554432pack_report:core.packedGitLimit=268435456pack report:pack usedctr=9pack report:pack mmapcalls=5pack_report:pack_open_windows=1/1packreport:packmapped=1356/1356你会发现，在它成功执行完毕以后，会给出一堆有关已完成工作的数据上例在一个分支导入了5次提交数据，包含了18个对象现在可以运行git log来检视新的历史$git log-2commit10bfe7d22cel5ee25b60a824c8982157ca593d41Author:ScottChaconschacon@example.com Date:Sun May312:57:392009-0700importedfrom currentcommit7e519590de754d079dd73b44d695a42c9d2df452Author:Scott Chaconschacon@example.com Date:Tue Feb301:00:002009-0700imported fromback_20090203就它了——一个干净整洁的Git仓库需要注意的是此时没有任何内容被检出——刚开始当前目录里没有任何文件要获取它们，你得转到master分支的所在$Is$git reset-hard masterHEAD isnow at10bfe7d importedfrom current$Isfile.rb libfast-import还可以做更多——处理不同的文件模式，二进制文件，多重分支与合并,标签，进展标识等等一些更加复杂的实例可以在Git源码的contib/fast-import目录里找到；其中较为出众的是前面提过的git-p4脚本
8.3总结现在的你应该掌握了在Subversion上使用Git以及把几乎任何先存仓库无损失的导入为Git仓库下一章将介绍Git内部的原始数据格式，从而是使你能亲手锻造其中的每一个字节，如果必要的话避免修改历史再重新推送的做法，也不要同时推送到并行的Git仓库来试图与其他Git用户合作Subersion只能保存单一的线性提交历史，一不小心就会被搞糊涂合作团队中同时有人用SVN和Git,一定要确保所有人都使用SVN服务来协作——这会让生活轻松很多初始设定为了展示功能，先要一个具有写权限的SVN仓库如果想尝试这个范例，你必须复制一份其中的测试仓库比较简单的做法是使用一个名为svnsync的工具较新的Subversion版本中都带有该工具，它将数据编码为用于网络传输的格式要尝试本例，先在本地新建一个Subversion仓库$mkdir/tmp/test-svn$svnadmin create/tmp/test-svn然后，允许所有用户修改revprop——简单的做法是添加一个总是以0作为返回值的pre-revprop-change脚本:$cat/tmp/test-svn/hooks/pre-revprop-change#!/bin/sh exit0;$chmod+x/tmp/test-svn/hooks/pre-revprop-change现在可以调用svnsync init加目标仓库，再加源仓库的格式来把该项目同步到本地了:$svnsync initfile:///tmp/test-svn.googlecode.com/svn/这将建立进行同步所需的属性可以通过运行以下命令来克隆代码$svnsync syncfile:///tmp/test-svn Committed revision
1.Copied propertiesforrevision
1.Committedrevision
2.Copied propertiesfor revision
2.Committedrevision
3....别看这个操作只花掉几分钟，要是你想把源仓库复制到另一个远程仓库，而不是本地仓库，那将花掉接近一个小时，尽管项目中只有不到100次的提交Subversion每次只复制一次修改，把它推送到另一个仓库里，然后周而复始——惊人的低效，但是我们别无选择入门有了可以写入的Subversion仓库以后，就可以尝试一下典型的工作流程了我们从git svnclone命令开始，它会把整个Subversion仓库导入到一个本地的Git仓库中提醒一下，这里导入的是一个货真价实的Subversion仓库，所以应该把下面的file:///tmp/test-svn换成你所用的Subversion仓库的URL:$git svnclone file:///tmp/test-svn-T trunk-b branches-t tagsInitialized emptyGitrepositoryin/Users/schacon/projects/testsvnsync/svn/.git/rl=b4e387bc68740b5af56c2a5faf4003ae42bdl35c trunkA m4/acx_pthread.m4Am4/stl_hash.m
4.・・r75=dl957f3b307922124eec6314el5bcda59e3d9610trunk Foundpossiblebranch point:file:///tmp/test-svn/trunk=\file:///tmp/test-svn/branches/my-calc-branch,75Found branchparent:my-calc-branchdl957f3b307922124eec6314el5bcda59e3d9610Followingparentwithdo_switchSuccessfully followedparent r76=8624824ecc0badd73f40ea2f01fce51894189b01my-calc-branch CheckedoutHEAD:file:///tmp/test-svn/branches/my-calc-branch r76这相当于针对所提供的URL运行了两条命令-----------git svninit加上gitsvn fetcho可能会花上一段时间我们所用的测试项目仅仅包含75次提交并且它的代码量不算大，所以只有几分钟而已不过，Git仍然需要提取每一个版本，每次一个，再逐个提交对于一个包含成百上千次提交的项目，花掉的时间则可能是几小时甚至数天-T trunk-b branches-t tags告诉Git该Subversion仓库遵循了基本的分支和标签命名法则如果你的主干（译注trunk,相当于非分布式版本控制里的master■分支,代表开发的主线），分支或者标签以不同的方式命名，则应做出相应改变由于该法则的常见性，可以使用-s来代替整条命令，它意味着标准布局（s是Standard layout的首字母），也就是前面选项的内容下面的命令有相同的效果$git svnclone file:///tmp/test-svn-s现在，你有了一个有效的Git仓库，包含着导入的分支和标签$git branch-a*master my-calc-branch tags/
2.
0.2tags/release-
2.
0.1tags/release-
2.
0.2tags/release-
2.
0.2rcl trunk值得注意的是，该工具分配命名空间时和远程引用的方式不尽相同克隆普通的Git仓库时，可以以origin/[branch]的形式获取远程服务器上所有可用的分支——分配到远程服务的名称下然而git svn假定不存在多个远程服务器，所以把所有指向远程服务的引用不加区分的保存下来可以用Git探测命令show-ref来查看所有引用的全名$git show-ref lcbd4904d9982f386d87f88fcelc24ad7c0f0471refs/heads/masteraeelecc26318164f355a883f5d99cff0c852d3c4refs/remotes/my-calc-branch03d09b0e2aad427e34a6d50ff147128e76c0e0f5refs/remotes/tags/
2.
0.250d02cc0adc9da4319eeba0900430ba219b9c376refs/remotes/tags/release-
2.
0.14caaa711a50c77879a91b8b90380060f672745cb refs/remotes/tags/release-
2.
0.2lc4cb508144c513ffl214c3488abe66dcb92916flcbd4904d9982f386d87f88fcelc24ad7c0f0471refs/remotes/trunk而普通的Git仓库应该是这个模样$git show-ref83e38c7a0af325a9722f2fdc56bl0188806d83al refs/heads/master3el5e38cl98baac84223acfc6224bb8b99ff2281refs/remotes/gitserver/master0a30dd3b0c795b80212ae723640d4e5d48cabdff refs/remotes/origin/master25812380387fdd55f916652be4881c6f11600d6f refs/remotes/origin/testing这里有两个远程服务器一个名为gitserver,具有一个master分支；另一个叫origin,具有master和testing两个分支注意本例中通过git svn导入的远程引用，Subversion的标签是当作远程分支添加的，而不是真正的Git标签导入的Subversion仓库仿佛是有一个带有不同分支的tags远程服务器提交到Subversion有了可以开展工作的本地仓库以后，你可以开始对该项目做出贡献并向上游仓库提交内容了，Git这时相当于一个SVN客户端假如编辑了一个文件并进行提交，那么这次提交仅存在于本地的Git而非Subversion服务器上$git commit-am Adding git-svn instructionsto theREADME，[master97031e5]Addinggit-svn instructionsto theREADME1files changed,linsertions+,1deletions-接下来，可以将作出的修改推送到上游值得注意的是，Subversion的使用流程也因此改变了——你可以在离线状态下进行多次提交然后一次性的推送到Subversion的服务器上向Subversion服务器推送的命令是git svndcommit:$git svndcommit Committingto file:///tmp/test-svn/trunk...M README,txtCommitted r79M README,txt r79=938bla547c2cc92033b74d32030e86468294a5c8（trunk）No changesbetween currentHEAD and refs/remotes/trunk Resettingto thelatestrefs/remotes/trunk所有在原Subversion数据基础上提交的commit会-------------提交到Subversion，然后你本地Git的commit将被重写，加入一个特别标识这一步很重要，因为它意味着所有commit的SHA-1指都会发生变化这也是同时使用Git和Subversion两种服务作为远程服务不是个好主意的原因之一检视以下最后一个commit，你会找到新添加的git-svn-id（译注即本段开头所说的特别标识）$git log-1commit938bla547c2cc92033b74d32030e86468294a5c8Author:schaconschacon@4c93b258-373f-llde-be05-5f7a86268029Date:Sat May222:06:442009+0000Addinggit-svn instructionstotheREADME git-svn-id:file:///tmp/test-svn/trunk@794c93b258-373f-llde-be05-5f7a86268029注意看，原本以97031e5开头的SHA-1校验值在提交完成以后变成了938bla5如果既要向Git远程服务器推送内容，又要推送到Subversion远程服务器，则必须先向Subversion推送（dcommit）,因为该操作会改变所提交的数据内容拉取最新进展如果要与其他开发者协作，总有那么一天你推送完毕之后，其他人发现他们推送自己修改的时候与你推送的内容产生冲突这些修改在你合并之前将一直被拒绝在git svn里这种情况形似$git svndcommit Committingto file:///tmp/test-svn/trunk...Merge conflictduringcommit:Your fileor directoryREADME,txt isprobably\out-of-date:resource outof date;try updatingat/Users/schacon/1ibexec/git-\core/git-svn line482为了解决该问题，可以运行git svnrebase,它会拉取服务器上所有最新的改变，再次基础上衍合你的修改$git svnrebase M README,txt r80=ff829ab914e8775c7c025d741beb3d523ee30bc4trunk First,rewinding headtoreplay yourwork ontop ofit...Applying:first userchange现在，你做出的修改都发生在服务器内容之后，所以可以顺利的运行dcommit:$git svndcommit Committingto file:///tmp/test-svn/trunk...M README,txtCommitted r81MREADME,txt r81二456cbe6337abe49154db70106dl836bcl332deed trunkNo changesbetweencurrent HEADandrefs/remotes/trunk Resettingtothelatestrefs/remotes/trunk需要牢记的一点是，Git要求我们在推送之前先合并上游仓库中最新的内容，而git svn只要求存在冲突的时候才这样做假如有人向一个文件推送了一些修改，这时你要向另一个文件推送一些修改，那么dcommit将正常工作$git svndcommit Committingto file:///tmp/test-svn/trunk...Mconfigure,ac Committedr84M autogen.sh r83=8aa54a74d452f82eeel0076ab2584clfc424853b trunkM configure,ac r84二cdbac939211ccbi8aa744e581e46563af5d962d0trunk W:d2f23b80f67aaaalf6f5aaef48fce3263ac71a92andrefs/remotes/trunk differ,\usingrebase::100755100755efa5a59965fbbb5b2b0al2890fIb351bb5493cl8\015e4c98c482f0fa71e4d5434338014530b37fa6M autogen.sh First,rewinding headtoreplay yourwork ontop ofit...Nothing todo.这一点需要牢记，因为它的结果是推送之后项目处于一个不完整存在与任何主机上的状态如果做出的修改无法兼容但没有产生冲突，则可能造成一些很难确诊的难题这和使用Git服务器是不同的——在Git世界里，发布之前，你可以在客户端系统里完整的测试项目的状态，而在SVN永远都没法确保提交前后项目的状态完全一样及时还没打算进行提交，你也应该用这个命令从Subversion服务器拉取最新修改sit svnfetch能获取最新的数据，不过git svnrebase才会在获取之后在本地进行更新$git svnrebase Mgenerate descriptorproto.sh r82=bdl6df9173e424c6f52c337ab6efa7f7643282f1trunk First,rewinding headto replayyourwork ontop ofit...Fast-forwarded masterto refs/remotes/trunk.不时地运行一下gitsvnrebase可以确保你的代码没有过时不过，运行该命令时需要确保工作目录的整洁如果在本地做了修改，则必须在运行gitsvnrebase之前或暂存工作，或暂时提交内容——否则，该命令会发现衍合的结果包含着冲突因而终止Git分支问题。
个人认证
优秀文档
获得点赞 0
