svn 与 git 并用的使用流程（译）

Git SVN Workflow
（http://andy.delcambre.com/2008/03/04/git-svn-workflow.html）

注：翻译主要结合自己的使用实践及理解进行。

I know, I know, this is blog post number one million about Git and git-svn. This is primarily for my co-workers who are wanting to switch to git for our SVN based projects like I have. (If I get them with git-svn, next we can start hosting with git directly, Muhahaha!)

 

使用git-svn为更好地让svn用户向git迁移

First, a bit of background. Git was written by Linus Torvalds specifically for use by the linux kernel team. He had very specific ideas about how the version control system should work, and none of the offerings at that time satisfied his needs. Git is designed to be distributed (every clone is a full fledged git repository) and very very fast. It is also designed to be very easy not only to branch, but also to merge.
一点背景：Git由linus为内核开发团队编写。他对于版本应该如何管理具有清晰的认识，可是那时没有软件能满足他的要求。git被设计成分布式的，这意味着每个复本都是一个完整的git仓库，而且非常的快。而且，git被设计成进行分支与合并的操作是非常简单的。
Disclaimer: This is not intended to be the “correct” way to use git + svn, only the way that I use it. That said, here we go.

First, we assume that you have a subversion repository at http://example.com/svn/my_proj. You will need to create the git repo setup to pull from this repo.

首先，使用以下命令将svn的仓库拷贝下来。

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

This will initialize the git repo for pulling from svn. The -s indicates that you have a “standard” setup for your subversion repository. I.e. trunk/ branches/ and tags/. This command will not yet import anything from subversion.

以上命令将svn仓库拷贝下来，并以此为基础初始化git仓库，－s表示你的svn仓库具有标准的布局，例如，拥有trunk/,branches/,tags等目录。

git svn fetch

This command will fetch all revisions from subversion that you have not yet received. The first time you run this could take quite a while. There are options to only fetch some of the revisions, but I prefer to fetch the whole history the first time. This way blame and log show the whole thing.
这个命令将会从你的SVN仓库中取出所有未拿过的版本。第一次运行此命令的时候将会花费较多时间 。可以使用－r来获取指定的版本，但是建议将所有的版本都取下来。
Now you will have both the whole revision history for trunk, but also all of the branches on the svn server. You can see all of the branches with
现在，你已经将SVN TRUNK中的所有修改历史以及所有分支信息都下载下来了，你可以通过下面这个命令查看分支。
git branch -a

This will show all branches, including the remote branches.

Now that you have the entire subversion history stored locally, it can be useful to repack the repository. Right now, each revision has it’s own file, this command will pack those into bigger “pack” files. This will make the repository smaller, but also with many many fewer files
现在，你可以将仓库打包。这将为你节省空间。
git repack -d

Next you will want to do some actual work on the repository. It is not recommended to make changes in your master branch, so lets make a branch for the new feature.
接着，你就可以 完成自己的工作了，git推荐所有新功能的开发在分支上进行。使用如下命令创建分支并切换到该分支
git checkout -b new_feature

This will make a new branch (the -b) and switch to it (checkout). Once you have your new branch you make a bunch of changes and add a new file or two. You need to add any new files so git knows to track them. You can do this with:
注：你也可以使用下面这种方法来做分支并切换

               git branch new_feature

               git checkout new_feature

 

当你进入新的分支后，则可以在此分支中进行操作，比如创建新文件，并修改等。
git add path/to/new_file

Now, once you are happy with this new feature and have it tested. You can commit it to git. This is one place where git diverges from subversion. Files you have changed aren’t automatically staged for committing. So right now if you try to commit, you will commit the file that you added in the above command, but nothing you changed (adding a file stages it). So you have two options at this point, you can manually stage each file you want to commit, you will want to do it this way if you don’t want to commit all the changes you have made. That will look something like

git add path/to/edited_file
git add another/edited/file
git commit -m "commit message"
当进行了所有的操作后，你需要将修改后的以及新增加的文件 都用add将之staged，然后用commit将之提交到git仓库
If you want to commit all of the changes you have made, and you have added all of the new files, you can automatically commit all changes, no need to stage. This is how I normally do things. That looks like:
当然，你也可以用下面的方法简化操作。
git commit -a -m "commit message"

The -a tells git to commit all staged and unstaged changes.

So now you have these commits in git but they have not been pushed to subversion yet. You will need to get this commit into master first. You need to checkout the master repo, then merge back with the new feature.

现在，你已经提交了所有的更新到分支，以下命令将回到主分支，并把刚才开发分支的更新合并到主分支。

git checkout master
git merge new_feature

It is likely this merge will work without any conflicts, but if not you will need to fix the conflicts then commit.
这里，可能需要处理冲突，因为你可以自己有多个分支，而且各个分支在合并到主分支可能会存在冲突，因此你可能需要解决文件冲突后然后再提交。
Once you have the commit back in the master repo, you will need to resync the master branch to the svn repo to make sure you don’t commit conflicts.
当你解决完git仓库的合并后，现在你可以重新确认一遍SVN仓库有无更新（这在多人开发的时候会出现，因为在你开发新功能的时候，其它人可能已经提交了新的功能上去）。
git svn rebase

This will rebase the master branch to the subversion trunk. Next, you need to push the commit to subversion.
上述命令使本地与远程SVN同步之后，你可能还需要处理冲突，待处理完后，你可以用以下命令，将自己增加的新功能合并到SVN仓库中
git svn dcommit

That’s it! That is the basic circle between an initial checkout back to a commit. I will be going through the different git commands in the next few weeks to go over how they work in more detail. Here are the things I am planning on covering:
就是这样了。以上流程是从最开始的建立仓库到开发新功能到合并回SVN仓库的整个流程。
    * git reset
    * git rebase
    * git log
    * git stash
    * git merge
    * git mergetool

 

 

 

ref:

http://www.viget.com/extend/effectively-using-git-with-subversion/

http://andy.delcambre.com/2008/03/04/git-svn-workflow.html

http://www.vilain.net/talks/git-svn/intro.html