Today, Google announced they were adding Git support to Google Code. This is certainly the most requested feature, and one I’ve been patiently waiting on. I move from Google Code’s SVN repositories to GitHub’s Git repositories almost 2 years ago. I love GitHub, but frankly, I’d rather have one less account to worry about and move over to Google Code with a few projects. Both have their advantages, and I’m not completely entirely convinced Google Code is better, but we will see.
As for the comparison between GitHub and Google Code, I miss the ability to follow projects like you can in GitHub. However, Google Code provides many methods to follow a project in “Project Feeds”. They can be found at http://code.google.com/p/PROJECT/feeds, such as Atom feeds of project updates, wiki updates, issues, source changes, etc. This allows you to integrate the updates into your existing tools, such as Google Reader, rather than going to the GitHub website. I will probably keep my account just for that. So far, I haven’t found the same functionality in Google Code. The wikis seems about the same. Google code does have a similar function to GitHub’s forking and pull request with clone and code review. Google seems to have integrated their Gerrit project for code review, which I’ve heard is fantastic for merging code, and is used extensively for the Android project, which is also run on Git. Google Code does provide 4GB of space per free project, where as GitHub only provides 300MB, though that can be adjusted with an email to their support. GitHub has a way to download the current source as a .zip or .tar.gz, which Google seems to be lacking. Google Code does have a way to script your uploads, which I like very much. They provide an easy way to use Python to upload files for download. I think this is handy, because I have always wished for a build server to work with GitHub more easily. This could easily be used to build .deb or .rpm packages and have them uploaded and downloaded by users. There are some methods to do this with GitHub, but none provided by the company themselves.
We are going to copy up all the history and branches from our projects. If we just copied the files into the new cloned Google repository, we’d only have the files, and no history. First, head over to create a new Google Code project. Create your project as normal, selecting Git as your version control system. Now, head to the terminal, so we can avoid typing in our password all the time.
nano ~/.netrc ----- machine code.google.com login YOUR_LOGIN password YOUR_PASSWORD ----- chmod 500 ~/.netrc
This will create a file that is used each time you try to interact with Google’s Git server, containing your login details. By chmod’ing it, no one but you should be able to read or write it.
Now head into your existing GitHub repository. If you don’t have it locally on your machine, just clone the repository like so:
git clone git@github.com:username/example_project.git
We are going to add the Google server as a new repository, and from there we will clone each branch into the Google repository. This is kind of a pain, but I did not see an easier way to clean each branch. Hopefully someone can prove me wrong.
# Move into the Git directory we just cloned. cd example_project # I'm going to call the new repository "google". I never much liked "origin". git remote add google https://code.google.com/p/example_project/ # Push all branches to the google repository git push google --all # Optional: Remove old repo, assuming your GitHub repo is called origin git remote rm origin # If you're hung up on the name "origin" you can rename the repo nano .git/config ----- # Change: [remote "google"] # To: [remote "origin"]
That’s everything. If you want a more in depth look at how to use Git, check out my Git Guide, which has a bunch of shortcuts and a link to an even better article.
Is there any particular reason you moved from svn to git? Is this just personal preference or are there a lot of pros that made you switch?
I use svn for my own projects and so does the company I work for, and I haven’t run into any problems. I notice that people, particularly those coding in ruby, tend to use git and I am curious to know why.
Also, is it easy to setup a git service to run your own repos? I prefer to host things on my own server rather than a third party (be it github or google code).
Thanks!
On top of what Ulrik said, check the link at the end of the article for my article on shortcuts in Git, which links to a great article that everyone who uses Git should read.
Mostly personal preference. I also like the idea of being able to sync to multiple servers (you could push to Google, GitHub and your own server all from one repository), and I love the idea of Heroku.com, where you simply commit to a certain branch in Git, and Heroku deploys your code form there. Heroku is a Ruby on Rails hosting platform, so maybe that’s why they love Git? Not sure. SVN isn’t as reliant on POSIX compatibility as Git is, so SVN will work better on Windows. I don’t use Windows, so this isn’t a concern for me. I had some initial problems with SVN and looked for other things, most likely because I didn’t fully know what I was doing at the time. I’ve loved using Git, and have seen no reason to change yet. It is very nice to have the entire repository local, so you can branch, merge, and commit a bunch of times before pushing to the server. It allows me to commit on minor changes, and push to the public server after I make a few minor changes and run tests. I like that.
You can certainly run your own server! Look into Gitosis, which is a hosting platform very similar to the structure GitHub uses, or the Alestic Git Server, which is a pre-packaged Amazon EC2 image running gitolite, another great Git hosting software.
git push –all
Oh, duh. Can’t believe I missed that. Thank you! Updating the article accordingly.
Brad; Basically, Git is faster and more powerful/flexible than SVN.
It is dead simple to get started with, just enter your project directory and type “git init”, and you have a repository and can start checking in files.
Being distributed means your local working copy is self-sufficient for all operations, you don’t technically _need_ a server. However, the distributed nature makes setting up a server _very_ simple (certainly easier than SVN). You simply run “git init” in a directory on the server that is to mirror the project, and you’re done. Then the above guide shows you how to push things there.
The distributed nature also has several other good side-effect such as being able to work off-line with all operations available, ability to rewrite local history. (Typo in the commit-message? No problem, as long as you haven’t submitted it anywhere.) Especially, branching/merging is intrinsic to distributed systems, so they are _really_ well supported.
Regarding Windows, I have played with Git on Windows, it definitely can be done, but I haven’t done anything serious with it.
A word of caution though. While Git is superior in most ways, it IS very different coming from a non-DVCS world, and unless you’re prepared to really learn the differences and why they are there, you’re probably better of with the familiar. Whatever works for you.
Personally, I almost never use SVN anymore. When needed, I’d rather work through git-svn than touch SVN directly.
An excellent run through! Thank you! I agree with all your points. I never really got into any other VCS, and Git feels natural now. I can’t imagine doing it a different way.
On a side note, I played Git for a second and updated your name
See. I wish this forums were DVCS, so I could rewrite the name of my last commit.