1,  Git SVN 工作流程

 尽管你可以从网上找到成千上万篇关于Git和git-svn,  但是本文主要介绍如何在一个以svn作为版本管理软件的项目里使用git。(假如你已经有了git-svn工具, 那我们就开始用git吧!)       先介绍些背景知识, Git 是 Linus Torvalds 为Linux内核开发的一套版本控制软件。他对版本控制有些特殊的要求，但是没有一个能满足他的要求。Git 有两个最大的优点分布式和执行速度快，它的设计不仅有操作简单的分支(branch)还有功能强大的合并(merge).

声明:这并非是唯一“正确”的方式来使用git + svn, 只是我这样用的, 让我们开始吧。

首先: 假设我们有个subversion仓库(repository)在 http://example.com/svn/my_proj. 你需要创建一个git仓库(repo)， 从subversion仓库中下载(pull).

# git svn init -s http://example.com/svn/my_proj

这个命令是初始化git仓库从远程的svn上下载。 -s 参数表示 svn 仓库具有标准布局（trunk、branches、tags）。

#git svn fetch

这个命令是从subversion取得所有的版本信息，在第一次运行的时候等待的时间比较长。当然你可以通过一些参数来控制只取得某些版本信息，但是我喜欢取得所以的历史版本信息。

现在你已经有了trunk所有版本信息，但是其他的分支的信息都在svn服务器上，你可以通过下面的命令查看所有的分支信息

# git branch -a
显示了所有的分支信息，也包括远程的分支信息。

现在在你的本地已经有了完整的subversion历史信息，对你的仓库进行打包就显的非常重要。因为每一个版本就是一个单独的文件，下面的命令就是把这些信息打包到一个大的"pack"文件里面。这样你的仓库就会小很多，但是还是会有些小文件。

#git repack -d

 

下一步就是在仓库里面做我们的工作，这里不推荐直接使用主干(master)分支来进行操作，因此我们要创建一个单独的分支new feature.

#git checkout -b new_feature

-b 参数创建一个新的分支并切换到这个分支(chackout). 在你有了新的分支后，就可以在这个分支里进行修改或增加文件。

 

如果你增加了文件需要通过下面的命令告诉git，git将自动跟踪这些新文件。

#git add path/to/new_file

现在你可以在你的新分支(new feature)里面工作，并且提交到Git. 你的修改并不会自动提交，如果你想提交上面你增加的文件，你有两个选择: 一个是提交所有修改过的文件，另一个是只提交你想提交(部分)的文件。如果你不想比较所有你修改过的文件可以通过下面的命令完成:

# git addpath/to/edited_file
#git add another/edited/file
# git commit -m"commit message"

如果你想提交你所有的操作, 并且已经通过git add增加了所有的新文件。可以通过下面的命令实现:

#git commit -a -m "commit message"

-a 参数是提交所有的变更.

 

现在你已经提交到git里面，但是还没有提交到subversion服务器上。应该把你的内容提交到master分支上。你需要先取得master仓库，然后与你创建的分支(new feaure)合并

# git checkout master
# git mergenew_feature
这次合并没有任何冲突(conflicts), 如果有冲突的话，你应该先修正冲突然后在提交。

一旦你提交到master仓库中，就需要让master分支与svn 仓库同步，并且不能有冲突(如果有冲突就必须修正)

#git svn rebase

master 分支与subversion 的trunk同步后，就应该把master提交到subversion仓库。

# git svn dcommit

 

 

 

 2， Git 与 Subversion

 

当前，大多数开发中的开源项目以及大量的商业项目都使用 Subversion 来管理源码。作为最流行的开源版本控制系统，Subversion 已经存在了接近十年的时间。它在许多方面与 CVS 十分类似，后者是前者出现之前代码控制世界的霸主。

Git 最为重要的特性之一是名为 git svn 的 Subversion 双向桥接工具。该工具把 Git 变成了 Subversion 服务的客户端，从而让你在本地享受到 Git 所有的功能，而后直接向 Subversion 服务器推送内容，仿佛在本地使用了 Subversion 客户端。也就是说，在其他人忍受古董的同时，你可以在本地享受分支合并，使暂存区域，衍合以及 单项挑拣等等。这是个让 Git 偷偷潜入合作开发环境的好东西，在帮助你的开发同伴们提高效率的同时，它还能帮你劝说团队让整个项目框架转向对 Git 的支持。这个 Subversion 之桥是通向分布式版本控制系统（DVCS, Distributed VCS ）世界的神奇隧道。

 

git svn

Git 中所有 Subversion 桥接命令的基础是 git svn 。所有的命令都从它开始。相关的命令数目不少，你将通过几个简单的工作流程了解到其中常见的一些。

值得警戒的是，在使用 git svn 的时候，你实际是在与 Subversion 交互，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

exit 0;

$ chmod +x  /tmp/test-svn/hooks/pre-revprop-change

 

现在可以调用 svnsync init 加目标仓库，再加源仓库的格式来把该项目同步到本地了：

$ svnsync init  file:///tmp/test-svn http://progit-example.googlecode.com/svn/

 

这将建立进行同步所需的属性。可以通过运行以下命令来克隆代码：

$ svnsync syncfile:///tmp/test-svn

别看这个操作只花掉几分钟，要是你想把源仓库复制到另一个远程仓库，而不是本地仓库，那将花掉接近一个小时，尽管项目中只有不到 100 次的提交。 Subversion 每次只复制一次修改，把它推送到另一个仓库里，然后周而复始——惊人的低效，但是我们别无选择。

 

入门

有了可以写入的 Subversion 仓库以后，就可以尝试一下典型的工作流程了。我们从 git svn clone 命令开始，它会把整个 Subversion 仓库导入到一个本地的 Git 仓库中。提醒一下，这里导入的是一个货真价实的 Subversion 仓库，所以应该把下面的 file:///tmp/test-svn 换成你所用的 Subversion 仓库的 URL：

$ git svn clone file:///tmp/test-svn -T trunk -b branches -t tags

这相当于针对所提供的 URL 运行了两条命令—— git svn init 加上 gitsvn fetch 。可能会花上一段时间。我们所用的测试项目仅仅包含 75 次提交并且它的代码量不算大，所以只有几分钟而已。不过，Git 仍然需要提取每一个版本，每次一个，再逐个提交。对于一个包含成百上千次提交的项目，花掉的时间则可能是几小时甚至数天。

-T trunk -b branches -t tags 告诉 Git 该 Subversion 仓库遵循了基本的分支和标签命名法则。如果你的主干(译注：trunk，相当于非分布式版本控制里的master分支，代表开发的主线），分支或者标签以不同的方式命名，则应做出相应改变。由于该法则的常见性，可以使用 -s 来代替整条命令，它意味着标准布局（s 是 Standard layout 的首字母），也就是前面选项的内容。下面的命令有相同的效果：

$ git svn clone file:///tmp/test-svn -s

 

 

现在，你有了一个有效的 Git 仓库，包含着导入的分支和标签：

$ git branch -a

 

 

值得注意的是，该工具分配命名空间时和远程引用的方式不尽相同。克隆普通的 Git 仓库时，可以以origin/[branch] 的形式获取远程服务器上所有可用的分支——分配到远程服务的名称下。然而 git svn假定不存在多个远程服务器，所以把所有指向远程服务的引用不加区分的保存下来。可以用 Git 探测命令show-ref 来查看所有引用的全名。

$git show-ref 

 

而普通的 Git 仓库应该是这个模样：

$ git show-ref

 

这里有两个远程服务器：一个名为 gitserver ，具有一个 master分支；另一个叫 origin，具有 master 和testing 两个分支。

注意本例中通过 git svn 导入的远程引用，（Subversion 的)标签是当作远程分支添加的，而不是真正的 Git 标签。导入的 Subversion 仓库仿佛是有一个带有不同分支的 tags 远程服务器。

 

 

提交到 Subversion

有了可以开展工作的（本地）仓库以后，你可以开始对该项目做出贡献并向上游仓库提交内容了，Git 这时相当于一个 SVN 客户端。假如编辑了一个文件并进行提交，那么这次提交仅存在于本地的 Git 而非 Subversion 服务器上。

$ git commit -am 'Adding git-svn instructions to the README'

 

 

接下来，可以将作出的修改推送到上游。值得注意的是，Subversion 的使用流程也因此改变了——你可以在离线状态下进行多次提交然后一次性的推送到 Subversion 的服务器上。向 Subversion 服务器推送的命令是 git svn dcommit：

$ git svn dcommit 

 

所有在原 Subversion 数据基础上提交的 commit 会一一提交到 Subversion，然后你本地 Git 的 commit 将被重写，加入一个特别标识。这一步很重要，因为它意味着所有 commit 的 SHA-1 指都会发生变化。这也是同时使用 Git 和 Subversion 两种服务作为远程服务不是个好主意的原因之一。检视以下最后一个 commit，你会找到新添加的 git-svn-id （译注：即本段开头所说的特别标识）：

$git log -1

 

注意看，原本以 97031e5 开头的 SHA-1 校验值在提交完成以后变成了 938b1a5 。如果既要向 Git 远程服务器推送内容，又要推送到 Subversion 远程服务器，则必须先向 Subversion 推送（dcommit），因为该操作会改变所提交的数据内容。

 

 

拉取最新进展

如果要与其他开发者协作，总有那么一天你推送完毕之后，其他人发现他们推送自己修改的时候（与你推送的内容）产生冲突。这些修改在你合并之前将一直被拒绝。在 git svn 里这种情况形似：

$ git svn dcommit

Committing to file:///tmp/test-svn/trunk ...Merge conflict during commit: Your file or directory 'README.txt' is probably \out-of-date: resource out of date; try updating at /Users/schacon/libexec/git-\core/git-svn line 482

为了解决该问题，可以运行 git svn rebase ，它会拉取服务器上所有最新的改变，再次基础上衍合你的修改：

$git svn rebase

 

现在，你做出的修改都发生在服务器内容之后，所以可以顺利的运行 dcommit ：

$git svn dcommit 

 

需要牢记的一点是，Git 要求我们在推送之前先合并上游仓库中最新的内容，而 git svn 只要求存在冲突的时候才这样做。假如有人向一个文件推送了一些修改，这时你要向另一个文件推送一些修改，那么dcommit 将正常工作：

$ git svn dcommit

 

这一点需要牢记，因为它的结果是推送之后项目处于一个不完整存在与任何主机上的状态。如果做出的修改无法兼容但没有产生冲突，则可能造成一些很难确诊的难题。这和使用 Git 服务器是不同的——在 Git 世界里，发布之前，你可以在客户端系统里完整的测试项目的状态，而在 SVN 永远都没法确保提交前后项目的状态完全一样。

 

及时还没打算进行提交，你也应该用这个命令从 Subversion 服务器拉取最新修改。sit svn fetch 能获取最新的数据，不过 git svn rebase 才会在获取之后在本地进行更新 。

$ git svn rebase

 

不时地运行一下 git svn rebase 可以确保你的代码没有过时。不过，运行该命令时需要确保工作目录的整洁。如果在本地做了修改，则必须在运行 git svn rebase 之前或暂存工作，或暂时提交内容——否则，该命令会发现衍合的结果包含着冲突因而终止。

 

 

Git 分支问题

习惯了 Git 的工作流程以后，你可能会创建一些特性分支，完成相关的开发工作，然后合并他们。如果要用 git svn 向 Subversion 推送内容，那么最好是每次用衍合来并入一个单一分支，而不是直接合并。使用衍合的原因是Subversion 只有一个线性的历史而不像 Git 那样处理合并，所以 Git svn 在把快照转换为 Subversion 的 commit 时只能包含第一个祖先。

假设分支历史如下：创建一个 experiment 分支，进行两次提交，然后合并到 master 。在 dcommit 的时候会得到如下输出：

$git svn dcommit

Committing to file:///tmp/test-svn/trunk ... M CHANGES.txtCommitted r85 M CHANGES.txtr85 = 4bfebeec434d156c36f2bcd18f4e3d97dc3269a2 (trunk)No changes between current HEAD and refs/remotes/trunkResetting to the latest refs/remotes/trunkCOPYING.txt: locally modifiedINSTALL.txt: locally modified M COPYING.txt M INSTALL.txtCommitted r86 M INSTALL.txt M COPYING.txtr86 = 2647f6b86ccfcaad4ec58c520e369ec81f7c283c (trunk)No changes between current HEAD and refs/remotes/trunkResetting to the latest refs/remotes/trunk

在一个包含了合并历史的分支上使用 dcommit 可以成功运行，不过在 Git 项目的历史中，它没有重写你在experiment 分支中的两个 commit ——另一方面，这些改变却出现在了 SVN 版本中同一个合并 commit 中。

在别人克隆该项目的时候，只能看到这个合并 commit 包含了所有发生过的修改；他们无法获知修改的作者和时间等提交信息。

 

 

Subversion 分支

Subversion 的分支和 Git 中的不尽相同；避免过多的使用可能是最好方案。不过，用 git svn 创建和提交不同的 Subversion 分支仍是可行的。

 

 

创建新的 SVN 分支

要在 Subversion 中建立一个新分支，需要运行 git svn branch [分支名] To create a new branch in Subversion, you run git svn branch [branchname]:

$ git svn branch opera

 

相当于在 Subversion 中的 svn copy trunk branches/opera 命令并且对 Subversion 服务器进行了相关操作。值得提醒的是它没有检出和转换到那个分支；如果现在进行提交，将提交到服务器上的 trunk， 而非 opera。

 

 

切换当前分支

Git 通过搜寻提交历史中Subversion 分支的头部来决定 dcommit 的目的地——而它应该只有一个，那就是当前分支历史中最近一次包含 git-svn-id 的提交。

如果需要同时在多个分支上提交，可以通过导入 Subversion 上某个其他分支的 commit 来建立以该分支为 dcommit 目的地的本地分支。比如你想拥有一个并行维护的 opera 分支，可以运行

$ git branch opera remotes/opera

然后，如果要把 opera 分支并入 trunk （本地的 master 分支），可以使用普通的 git merge。不过最好提供一条描述提交的信息（通过 -m），否则这次合并的记录是 Merge branch opera ，而不是任何有用的东西。

记住，虽然使用了 git merge 来进行这次操作，并且合并过程可能比使用 Subversion 简单一些（因为 Git 会自动找到适合的合并基础），这并不是一次普通的 Git 合并提交。最终它将被推送回 commit 无法包含多个祖先的 Subversion 服务器上；因而在推送之后，它将变成一个包含了所有在其他分支上做出的改变的单一 commit。把一个分支合并到另一个分支以后，你没法像在 Git 中那样轻易的回到那个分支上继续工作。提交时运行的 dcommit 命令擦除了全部有关哪个分支被并入的信息，因而以后的合并基础计算将是不正确的—— dcommit 让 git merge 的结果变得类似于 git merge --squash。不幸的是，我们没有什么好办法来避免该情况—— Subversion 无法储存这个信息，所以在使用它作为服务器的时候你将永远为这个缺陷所困。为了不出现这种问题，在把本地分支（本例中的 opera）并入 trunk以后应该立即将其删除。

 

对应 Subversion 的命令

git svn 工具集合了若干个与 Subversion 类似的功能，对应的命令可以简化向 Git 的转化过程。下面这些命令能实现 Subversion 的这些功能。

 

SVN 风格的历史

习惯了 Subversion 的人可能想以 SVN 的风格显示历史，运行 git svn log 可以让提交历史显示为 SVN 格式：

$ git svn log

关于 git svn log ，有两点需要注意。首先，它可以离线工作，不像 svn log 命令，需要向 Subversion 服务器索取数据。其次，它仅仅显示已经提交到 Subversion 服务器上的 commit。在本地尚未 dcommit 的 Git 数据不会出现在这里；其他人向 Subversion 服务器新提交的数据也不会显示。等于说是显示了最近已知 Subversion 服务器上的状态。

 

SVN 日志

类似 git svn log 对 git log 的模拟，svn annotate 的等效命令是 git svn blame [文件名]。其输出如下：

$ git svn blame

同样，它不显示本地的 Git 提交以及 Subversion 上后来更新的内容。

 

SVN 服务器信息

还可以使用 git svn info 来获取与运行 svn info 类似的信息：

$ git svn info

它与 blame 和 log 的相同点在于离线运行以及只更新到最后一次与 Subversion 服务器通信的状态。

 

略 Subversion 之所略

假如克隆了一个包含了 svn:ignore 属性的 Subversion 仓库，就有必要建立对应的 .gitignore 文件来防止意外提交一些不应该提交的文件。git svn 有两个有益于改善该问题的命令。

第一个是 git svn create-ignore，它自动建立对应的 .gitignore 文件，以便下次提交的时候可以包含它。

第二个命令是 git svn show-ignore，它把需要放进 .gitignore 文件中的内容打印到标准输出，方便我们把输出重定向到项目的黑名单文件：

$ git svn show-ignore > .git/info/exclude

这样一来，避免了 .gitignore 对项目的干扰。如果你是一个 Subversion 团队里唯一的 Git 用户，而其他队友不喜欢项目包含 .gitignore，该方法是你的不二之选。

 

 

Git-Svn 总结

git svn 工具集在当前不得不使用 Subversion 服务器或者开发环境要求使用 Subversion 服务器的时候格外有用。不妨把它看成一个跛脚的 Git，然而，你还是有可能在转换过程中碰到一些困惑你和合作者们的迷题。为了避免麻烦，试着遵守如下守则：

保持一个不包含由   git merge   生成的 commit 的线性提交历史。将在 主线分支外进行的开发通通衍合回主线；避免直接合并。不要单独建立和使用一个 Git 服务来搞合作。可以为了加速新开发者的克隆进程建立一个，但是不要向它提供任何不包含  git-svn-id  条目的内容。甚至可以添加一个  pre-receive  挂钩来在每一个提交信息中查找  git-svn-id  并拒绝提交那些不包含它的 commit。

如果遵循这些守则，在 Subversion 上工作还可以接受。然而，如果能迁徙到真正的 Git 服务器，则能为团队带来更多好处。

 

 

 

 

2, git svnfetch; git svnclone; git svnrebase;  git svndcommit; git svnbranch;  git svntag;