Develop with Git on a Google Code Project

Tuesday, May 20, 2008 at 8:48 AM



Do you often work offline? Wish you could make local commits that you can reorganize and upload later? Would you like to have your own copy of the entire history of the project which you can peruse at your leisure?

Do you want to serve code and its history to others? Have changes you want to share but it's too early for the public?

Working on several issues in parallel? Need to save some of those experimental changes after all? Need to create, merge, clone and otherwise manipulate branches cheaply and offline?

You can do all this, and more, with Git, a version control system rapidly growing in popularity. You can readily find Git tutorials, but since I'm writing this post, I'll shamelessly plug my own guide to Git!

Although Google Code natively speaks Subversion, you can easily use Git during development. Searching for "git svn" suggests this practice is widespread, and we too encourage you to experiment with it.

We focus on importing a complete Git repository from a Google Code project organized in the recommended fashion. The git-svn manpage thoroughly describes how to handle other cases such as nonstandard layouts, importing only a few revisions, sharing exported repositories, and so on.

1. Import

First we perform the equivalent of a svn checkout. In an empty subdirectory, run:
$ git svn clone --username your-name -s https://your-project.googlecode.com/svn
# older versions of git: replace "-s" with "-Ttrunk -bbranches -ttags"
Like a Subversion checkout, you now have a local copy of your project. Unlike a Subversion checkout, you also have a local copy of the entire history of the project. Try:
$ git log          # print summary of history
$ git diff HEAD^^ # diff against two revisions ago
$ gitk # graphical history browser
$ qgit # Qt-based history browser
These read from local disk, and work even when you're offline.

2. Develop

You now have a fully fledged version control system at your fingertips. You can checkpoint locally. You can create, merge, and destroy branches cheaply. You can checkout long-lost ancient code. You can stockpile and reorganize your commits.

Any Git tutorial teaches these abilities. We'll content ourselves with simple examples.

First, the basics. Edit code as usual, but if you add or remove files, type:
$ git add FILENAME...
or
$ git rm FILENAME...
There's no need to inform Subversion as git-svn will do so later. In fact, we only talk to Subversion via git-svn, and never run pure svn commands.

The only other git command you must know is:
$ git commit -a
which saves the current state of your project locally. You can see them with git log. Commit early and commit often!

Now for a couple of tricks. Let's say you've made several commits and suppose you want to undo the last one:
$ git reset --hard HEAD^
Or suppose you want to get a certain file from five commits ago:
$ git checkout HEAD~5 foo.c
We've barely scratched the surface. There are countless other features worth learning, particularly Git's extraordinary lightweight branches.

3. Update

Periodically, you should get online and fetch the latest changes from Google Code with:
$ git svn rebase   # think "svn update"

4. Export

Submit your commits to Google Code with:
$ git svn dcommit  # think "svn commit"
This converts each of your Git commits into Subversion commits and uploads them, provided your repository is up-to-date. To keep working, go back to step 2.

Stay Tuned!

We've seen it's easy to setup Git with a Google Code project. If distributed version control systems sound intimidating, the above is a great way to get your feet wet. You can always delete the directory and go back to Subversion.

But what if you keep your project in a Git repository, and you want to export it to Google Code? So you'd have a canonical read-only Subversion mirror of your project?

Exporting a Git project to Google Code requires only a handful of commands. We'll show you how in a future post.

13 comments:

powerfox said...

Benjamin, thanks for the article. I looked through your guide and it rocks. But unfortunately there is a problem with svn:externals (git doesn't handle it), I solve the problem with creating another repo and symlinks in the main repo.
Git-svn rocks, but it's just svn over git: only your working repo will have the information about many things, that will die in the svn. Pure git is always better and actually I don't understand what stops google from adding such feature to the GCP.

Dustin said...

To expand a bit on what powerfox said, this is really not much different from just using svn.

What you do get:

1) Offline commits.
2) Offline branches.

What you don't get:

1) Useful collaboration workflows.
2) Ability to work effectively on more than one computer (since all of the merge information is lost).

What I (and a few other people I've seen) have been doing is to just put my code somewhere else and change the source tab to point to a wiki page that describes how to get my code from git.

It'd be nice to be able to use all of google code, but as it is, the issue tracker is the only part that's particularly useful to me.

Vinnl said...

I was just going to ask that last thing - bring that future post on :)

imyousuf said...

Nice article for beginners using wanting to know how to use GIT with google code.

In general when working with git-svn I follow a work flow (as discipline) and it works fine.
Firstly, why the work flow, git svn dcommit actually replays the work you have done till now, so during the commit if for some reason it fails you might loose all commits after the one that failed. I was following the work flow before facing the problem and after facing it I realized how important my flow is.
So what I do is keep the SVN history in the master branch. Create a new branch (I name it 'work') do all my off-line works in that branch and then merge work into master and then do svn dcommit. Commands would look like -

git checkout -b work # create a new branch
.....# work and make commits
git checkout master
git svn fetch
git rebase master work
git checkout master
git merge work
git svn dcommit

You could also have a script for this. If the commit fails you can simply do -
git reset --hard HEAD # clean the index
git rebase master work
# follow the rest of the commands from above after resolving the problems

Bob Aman said...

Looking forward to that future post. I've tried several times to accomplish that, have yet to figure out how to do it.

In any case, I'd really just prefer to see Google Code allow Git natively. That'd rock.

Ben Lynn said...

Thanks for all your comments. Some thoughts:

Lack of svn:externals support is a common complaint. Creating extra repos and symlinking is a good workaround, though I've read of others recommend Git submodules instead, as you can keep track of the revisions of the externals. I think it's only a matter of time before somebody adds this feature to git-svn.

An interrupted dcommit is certainly annoying, but you won't permanently lose commits (unless you run git-gc --prune). You can look through .git/log/refs/HEAD to find the old HEAD, rebase the appropriate commits and run dcommit again. Nevertheless if dcommit fails frequently for you, I suspect your method is more convenient.

I agree that there are limitations to git-svn, but I claim you still can work on more than one computer and get useful collaboration workflows, provided you run a Git daemon, a webserver, or sshd.

As for Git support at Google Code: I'd love to see this too, but bear in mind that Git is relatively young and still evolving. If Git were to become mainstream, we would support it soon enough.

With this in mind, I'm hoping this post will encourage more developers to test drive Git. And even if it doesn't suit them, at least they may understand our fanaticism!

powerfox said...

Ben, not sure git submodules work. Didn't test it, but when I googled my problem I found this: http://panthersoftware.com/articles/view/3/svn-s-svn-externals-to-git-s-submodule-for-rails-plugins
"git-svn is not able to git-svn dcommit any repository that contains sub-modules."
More detailed description in the git's mailing list (but no asnwers): http://marc.info/?l=git&m=120566485203728&w=2

Julio Biason said...

Ok, I know this is not a GoogleCode problem, but...

I'm trying to import my project into Git, but it's not importing the branches correctly (Git-svn make it look like it's a flat import, so branches and trunk are being merged already.)

Any ideas why this is happening? (Git 1.5.4.5, if you're wondering.)

Dustin said...

Julio:

Actually, that is a bit of a google problem. svn doesn't have branches (or tags) other than by a convention of where you copy your trees. git-svn knows how to honor that convention (and you can tell it where you're drifting from it), but even if you get that far, it has to guess a lot because svn doesn't properly track branches.

Google doesn't use normal svn conventions, so tools that expect a consistent layout might get confused. I'd recommend getting a newer version of git and manually telling git-svn which of your tree copies you mean to be branches.

Dustin said...

Ben,

"I agree that there are limitations to git-svn, but I claim you still can work on more than one computer and get useful collaboration workflows, provided you run a Git daemon, a webserver, or sshd."

Please read the CAVEATS section of the git-svn documentation. I've certainly dealt with the issues of trying to work on more than one machine due to svn's lack of merge tracking. If you're doing the most simple thing possible, it'll work, but that didn't meet my needs.

I do agree that git-svn is a better svn client than subversion's, but it's not where I'd place a ``good'' baseline.

powerfox said...

Ben,

“As for Git support at Google Code: I'd love to see this too, but bear in mind that Git is relatively young and still evolving. If Git were to become mainstream, we would support it soon enough”.

It seems to me that google likes to be on the edge of technology ;)
I like google services, but when I choose hosting service I would prefer git hoster. Now there are a lot of projects which use sf.net with a link to Git repo. Google may benefit from adding Git support even now: everybody will choose Google Code.

DV said...

Google has also released two very helpful tech talks about Git, each of them approximately one hour:

Linus Torvalds:
http://www.youtube.com/watch?v=4XpnKHJAok8

Randal Schwartz: http://www.youtube.com/watch?v=8dhZ9BXQgc4

powerfox said...

I work with SVN in another way (and I use svn+ssh, so the method described above doesn't work if I don't mistake).
I use some branching tricks to commit to the KDE's svn. So this article can be useful for those who develop SVN projects using git:
http://kdevelop.org/mediawiki/index.php/KDevelop_4/Using_Git_for_Development