Revision as of 12:28, 20 July 2009

Getting started with git

Recommended reading

The Git Parable: Background information that will help you understand git and distributed revision control systems in general
Git to SVN crash course 5 minute introduction to git for experienced SVN users

Getting started

gitorious.org

• Create an account on gitorious.org the git hosting service used by Qt and now Amarok.
• On your user page, (that's at http://gitorious.org/~your_nick) click on "Manage SSH keys" and add your SSH key.
• Again from the user page, click on "Manage aliases" and add any email addresses you've ever used in KDE SVN. This way any commits you've made in the past are tracked back to you. If your gitorious email address is the only one you ever used, then this step isn't needed.
• Request one of the kde-developers admins to add you to the group (the same rules apply as KDE SVN account requests). This will give you push rights to Amarok. Lydia, Ian and Jeff are all admins.

Setup Amarok Clone

Gitorious has one address for cloning, and another for pushing. The pushing address can be used for cloning, so the easy thing to do is just use that.

git clone git@gitorious.org:amarok/amarok.git

This will create a directory 'amarok'. cd into that and start developing!

So what you will do 90% of the time:

git pull #update to latest code
#edit code, build, it works!
git status #to check if you want to commit all the modified files
git commit -a #the -a option commits all modified files. use git add to select them individualy
git push

Getting started for SVN experts

Getting started for Novices

Alternatives for users

- gitorious tarballs - svn snapshots

Rules for using Gitorious

1. Never, ever create a branch in our mainline repo. Ever. You can do it locally, but do *not* push it up.
2. Clone the repo and work on that. Add mainline as a remote branch in your local copy of your cloned repo. This will allow you to easily merge back and forth.
3. Pushing branches to your own clone of the mainline repo is fine, however, if you are doing bugfixing or feature branches, use *ONE BRANCH PER FEATURE/BUGFIX*. Gitorious will hopefully improve, but right now it has a downfall in that you can only merge from the start of a branch up to a selected end-point; you can't cherry-pick start and stop points. So if you work on feature A and merge it, then feature B, and want to merge in feature B, you'll have to merge from the start of the branch. So for now at least, just use one branch per feature/bugfix.

For members of the kde-developers group on gitorious only rule 1 is relevant. Outside contributers need to comply with 2 & 3 to be able to do a request pull.