How to Use git in the svn System

If you are using svn and want to switch to git and do not want to discard the existing svn code library, you can select git-svn. Let's talk about my experience from svn to git.
 
 
Start
Install the latest version of git. git 1.5.3 and later support git-svn. The cooperation between git and svn requires the help of this function.
 
Make some simple configurations after installation. The most direct approach is to create and modify ~ /. Gitconfig. Below is my. gitconfig
 
[User]
Name = Robin Lu
Email = --- @ gmail.com
[Color]
Diff = auto
Status = auto
Branch = auto
[Alias]
St = status
Rb = svn rebase
Ci = commit-
Co = checkout
[User] indicates the user's identity. The code you submit will automatically reference this identity information. [Color] set the color of command output. The [alias] section can simplify some common commands, such as simplifying git status to git st here.
 
Initialize the code library
First, use git-svn to initialize the local code library (repository)
 
Git svn clone-s svn-repository-url
The svn-repository-url section uses the url of the svn code base. If you want to check out from the trunk directory or a branch directory, replace-s with options such as-T and-B. For more information, see man git-svn. This command takes a long time, because all the submission history needs to be synchronized. Fortunately, this is only one time, and it will not be so slow in the future. After this step is completed, a complete code library is available locally, including all the history and logs of commit, which can be used for development.
 
However, before starting development, it is best to perform a garbage collection first:
 
Git gc
It collects and compresses the information in the code library. The most obvious function is to reduce disk space usage. This is especially effective for the first time.
 
You can check the status of the code library:
 
Git status
It should be on a branch called "master.
 
Use this command to display all branches ):
 
Git branch-
There is a "*" number in front of the master, which represents your current branch. Another branch is called trunk, which is a remote branch and corresponds to the remote svn code base. The master is actually a local branch of the trunk.
 
Next, configure the ignore file so that git can ignore files in directories that do not want to be added to the code library, similar to svn propset svn: ignore. The list of globally valid ignore files can be added to the./. git/info/exclude file. For example, I need to ignore all swp files generated by vi:
 
. *. Swp
You can create directory-related ignore File Settings in this directory. gitignore, and then add the content to be ignored. For example, if you want to ignore the log and tmp directories under the root directory, you can directly. add the following to gitignore:
 
Log
Tmp
Development Process
You can start working. After using git, you start to develop a new habit, that is, to create a new branch before work:
 
Git checkout-B new_branch
-After B is the branch name, you need to go to the new branch when creating it. Try to keep the master node from being committed to svn commit, so that a clean branch can be easily generated at any time.
 
Next, you can write code, modify a file, or add a file. If you want to see what has been modified, you can use:
 
Git diff
If you are not satisfied with a change and want to restore the original state, you can use:
 
Git checkout path/filename
Equivalent to svn revert
 
Git introduces the index concept. Before submission, you need to add the file to be submitted to the git index:
 
Git add path/filename1
Git add path/filename2
...
Then submit
 
Git commit-m "submit comments"
Each commit is used to submit the content in the index.
 
If you want to submit all modified files at a time, you can add them at a time and then submit
 
Git add.
Git commit-m "submit comments"
If you only modify the file and do not add a new file, run the following command:
 
Git commit-a-m "submit comments"
Add the modified file to the index and submit it. The entire process is completed at one time.
 
After adding the modified index to the index, you can use:
 
Git diff -- cached
It is suitable for the final code review before submission.
 
You can use
 
Git show
View the status of the current code library at any time during modification:
 
Git status
Equivalent to svn status
 
Delete and move an object:
 
Git rm file
Git mv file newfile
Submit to svn
After several rounds of work, to submit local content to remote svn, You can first synchronize the current branch with remote svn:
 
Git rebase
Then, submit all local modifications that have been merged into the master branch to svn.
 
Git svn dcommit
If a code conflict occurs during git svn rebase, manually resolve the conflict, use git add to add the modification to the index, and then continue rebase.
 
Git svn rebase -- continue
Disadvantages
Finally, let's talk about the shortcomings of this work method. This topic is a little more complex.
 
The working principles of svn and git are different after all. It is difficult for git to reproduce the non-linear features of code submission in svn. If git-merge or git-pull is used, it is committed to svn, the submission history of related branches may not be reflected in svn. From the perspective of svn users, we cannot tell whether this is a commit or a merge. Therefore, we recommend that you do not use merge or keep the code library linear during the collaboration with svn.
 
In my experience, if you don't care whether svn reflects the submission history, you can use merge. For example, after completing the job, you can merge the job branch into the master Branch:
 
Git checkout master
Git merge new_branch
Use the checkout command to switch back to the master branch, and then merge the content in the new branch. Then run git svn rebase and dcommit on the master branch. From the svn perspective, this is a commit. The submission history on new_branch cannot be reflected in svn. (In case of exceptions, we will discuss it later ).
 
Another solution is to keep the linear characteristics of the git code library as much as possible. For example, in the new_branch branch, rebase is performed with the master and then merged into the master Branch:
 
Git rebase master
Git checkout master
Git merge new_branch
Then dcommit is performed on the master to view the complete submission history in the svn code library.
 
If you see that this is a bit dizzy, you can simply ignore it, just follow the previous practice, directly dcommit in your work branch, and wait for a certain understanding of non-linear development, then let's look at the various situations.
 
Okay, you can work as you know.

From http://www.robinlu.com/blog/archives/194