How to use Git in an SVN system

If you're using SVN and you're going to switch to git and don't want to give up your existing SVN code base, you can choose GIT-SVN. Tell me about my own experience from SVN to git.

Begin

Installing the latest version of Git, which supports git-svn,git and SVN after Git 1.5.3, will help with this feature.

After installation, do some simple configuration. The most straightforward approach is to create a modified ~/.gitconfig. Here's My. Gitconfig

[User]        Name = Robin Lu        email = [email protected][color]        diff = auto        status = Auto        branch = Auto[alias]  st = s Tatus  RB = svn rebase  ci = commit-a  CO = Checkout

The [user] section indicates the identity of the user, and the code you submit will automatically reference this identity information. [Color] Sets the color of the command output. The [alias] section simplifies some common commands, such as simplifying git status to git St.

Initializing the code base

First use GIT-SVN to initialize the local code base (repository)

Git svn clone-s svn-repository-url

The Svn-repository-url section uses the URL of the SVN code library. If you want to check out from a trunk directory or a branch directory, replace-S with the-T,-B options. See Man git-svn for details. This command time is longer, because it is necessary to synchronize all the commit history, fortunately only this once, later not so slow. With this in place, a complete code base is available locally, including all commit history and log, which you can begin to use for your development work.

However, before you start development, it's a good idea to do a garbage collection first:

Git GC

It collects and compresses the information of the code base, the most obvious function is to reduce the disk space consumption. The first effect was particularly noticeable.

You can check the status of the code base:

git status

It should now be on a branch called "Master" (branch).

Use this command to display all the branches (branch):

Git branch-a

There is a * number in front of master, which represents the branch you are in, and another branch called Trunk, which is a remote branch (remote branch), which corresponds to a remotely SVN code base. Master is actually a local branch of the trunk.

Next, you need to configure the Ignore file, let git ignore some directories do not want to join the code base file, like SVN propset svn:ignore. A globally valid list of ignored files can be added to the./.git/info/exclude file. For example, I need to ignore all VI generated SWP files:

. *.swp

For directory-related ignore file settings, you can create the. Gitignore in this directory, and then add the content that needs to be ignored, such as I want to ignore directories such as log,tmp in the root directory, and you can add them directly to the. Gitignore in the root directory:

Logtmp

Development process

can start working. Use Git to start a new habit of creating a new branch before working:

Git checkout-b new_branch

-B is the name of the branch, and when you create it, you are going to the new branch. Try to keep a commit on master that is not submitted to SVN, so that you can easily produce a clean branch at any time.

Next you can write code, modify files or add files. If you want to see what has been changed, you can use:

Git diff

If you are dissatisfied with a change and want to revert to the original, you can use:

git checkout Path/filename

Equivalent to SVN revert

Git introduces the concept of an index, and before committing it, you need to add the file you want to submit to the GIT index:

git add path/filename1git add path/filename2 ...

Then submit

git commit-m "Submit Testimonials"

Each commit is the content in the commit index.

If you want to commit all the modified files at once, you can add them one at a time and then submit

git Add. Git commit-m "Submit Testimonials"

If you just modified and did not add a new file, you can use the following command directly:

Git commit-a-M "Submit Testimonials"

The modified file is added to the index and submitted, once the entire process is completed.

After modifying the index, if you want to see what is changed in the index content, you can use:

git diff--cached

It is appropriate to do the final code review before submitting.

To view the most recent submission, you can use the

Git show

Review the status of the current code base at any time in the modification:

git status

Equivalent to SVN status

Delete and move a file:

git rm filegit mv file NewFile

Submit to SVN

After a few rounds of work, to commit the local content to the remote SVN, you can synchronize the current branch with the remote SVN first:

Git rebase

All local modifications that have been merged into the master branch are then submitted to SVN

Git svn dcommit

If a code conflict occurs when Git svn rebase, you need to resolve the conflict manually, then use git add to add the modifications to the index and continue Rebase

Git svn rebase--continue

Disadvantages

Finally, the shortcomings of this way of working. This topic is a little bit more complicated.

Since SVN and git work differently, the non-linear nature of Git's code submissions is hard to reproduce in svn, and if you use Git-merge or git-pull and then commit to SVN, the commit history on the relevant branch may not be reflected on SVN. From an SVN user's point of view, it is not possible to tell whether this is a commit or a merge, so try not to use merge in conjunction with SVN, or try to keep the codebase as linear as possible.

My experience is that if you don't care if the SVN reflects the commit history, using merge is no harm. For example, once you have finished your work, you can merge your work branches into the main branch:

git checkout mastergit merge New_branch

Switch back to the master branch with the Checkout command, and then merge the contents of the new branch. Then do git svn rebase and dcommit on the master branch. From SVN's point of view, this is a commit history on commit,new_branch that is not reflected on SVN. (with exception, discussed later).

Another solution is to try to maintain the linear characteristics of the GIT code base. For example, in the New_branch branch, first and master do rebase, and then merge into the Master branch:

git rebase mastergit checkout mastergit Merge New_branch

Then do Dcommit on master, and you'll see the full commit history in the SVN codebase.

If you see this is a little dizzy, you can simply ignore it, just follow the previous approach, directly in your work branch dcommit, and so on the non-linear development have a certain understanding of the situation.

Well, basically knowing this will work.

How to use Git in an SVN system