利用者:Psy-Fi/Git-Svn

Why use git

---

svn is quite powerful but git has a few features that are worthy of consideration: Cheap branches, local branches and "rebasing".

• Cheap branches are important due to space considerations. svn forces you to duplicate the full branch tree in your hard drive, while git broadly speaking stores only the diffs for each branch.

• Local branches are important because they allow a developer to start working on different features without one feature interfering with the other. Combined with cheap branches, this means essentially that the preferred workflow with git is starting a branch every time a new feature/fix is developed. This may sound too much but it's actually trivial.
• Rebasing is essentially merging, but adds all the extra code of the branch on top of the "trunk", or branch being merged to. This means keeping all the commits of the branch, and makes changes nicely local and concentrated. Rebasing also adds the ability to reorganize your commits locally and squash many commits into one. This allows you to do quick and dirty state saves before doing a cleaned-up commit appropriate for sending to the server for all to admire.

git - svn

---

git svn is a package that can take the history of an svn repository and store it as a git repository locally on your hard drive. The package git-svn of your distro should take care of installation.

git works a bit differently than svn and the terminology can be a bit confusing. In git, all branches are local, meaning that when you commit, the code goes to the local repository in your hard drive. The command to commit to your local repository like that is, not surprisingly, "git commit". To synchronize with a remote repository you need a separate command. The equivalent of "svn commit", if we use a remote git repository, is "git push origin <branchname>". In git-svn it's a bit different because the remote repository is an svn server, while our local repository is a git repository. The command in this case is "git svn dcommit", and what it does is take all of your local commits since you last updated from svn, apply them (rebase) to the latest svn version, and send them as separate svn commits to the svn server. Basics

---

But let's start from the beginning, with each step in order.

To checkout an svn repository you need to issue git svn clone

This "git clone" is "svn checkout" in git lingo. This will copy the entire svn repository. Given that our repository is comprised of about 50000 commits and counting, it may be better to use

---

git svn clone -r<revision number> <url to branch svn server>

---

where revision number is the latest svn revision. This will only get the latest svn revision and start from there. You won't have the full svn history but in the beginning it won't be needed most probably

For example

---

git svn clone -r57064 https://svn.blender.org/svnroot/bf-blender/trunk/blender/

---

will get us trunk revision 57064 on a local directory called blender/

Next step is updating from the svn repository. This can be done by using

---

git svn rebase

---

while being inside the top directory of the repository (which would be "blender/" on our previous example with trunk)

This will allow us to keep our local repository in synch with the remote svn repository.

Commiting work

---

As explained above, when doing work in git we usually switch to a temporary local branch and after we are finished, we merge the branch commits on top of, (or rebase on) trunk on our local repository before sending them off to the svn server. The procedure goes as follows: While on trunk (called "master" on git)

---

git branch feature

---

This will create a branch named "feature" that is identical to the current master branch

---

git checkout feature

---

This will change the local repository to switch to the feature branch. Broadly speaking, you can imagine git repositories like many svn repositories in the same folder. So git branch will create the branch but git checkout actually changes the contents of the folder to reflect the contents of the other branch.

To change back to trunk, use

---

git checkout master

---

"master" here, is just a branch name, but on git it is the equivalent of trunk and on git-svn, it is the branch that will contain all the svn commits when doing git svn rebase.

After doing changes to your local repository, you can commit them to the local repository by using

---

git commit -a -m <commit message>

---

The -a flag means "Commit all modified files" and the -m flag is used to supply your commit mesage, which should be included in quotation marks "". Git will not commit any new files in the repository with the above command unless you manually add them using

---

git add <filename>

---

Using a folder as a filename adds the whole folder, subfolders and contained files to the repository, ready to be commited on the next commit.

It is common to checkout master and do git svn rebase, which will bring all commits from the svn directory to our local master branch. However, all branches are based off an older trunk commit this way. After doing some commits on our branch, we need to put our work on top of the current master branch before commiting. To do that, while we have a feature branch checked out, we use

---

git checkout feature
git rebase master

---

This will cause git to take our work and apply it on the latest commit in master. There may be some conflicts which we can solve in the usual way by editing the conflicted files and then issuing git rebase --continue.

Finally, after rebasing a branch to trunk the commits are ready to go to svn. To do that, issue

---

git checkout master
git merge feature
git svn dcommit

---

That's it for now.