@Marko: Why ‘git add’ when you’ve already added a file? Because, in git’s opinion, svn’s policy of automatically committing every change it can find is reckless. It’s easy to explicitly add files to the commit each time, and it cuts down on mistakes (like checking important passwords into the repository, oops). Personally, I much prefer this approach.

But, as Shaun says, if you don’t like creating each changeset by hand, you can just use ‘git commit -a’ to just use the shotgun approach.

so you don’t end up with 10000000 merge changesets

‘git status’ is also useful of course.

It is necessary to do ‘git gc’ occasionally to “reduce disk space and increase performance” – eg running ‘git log’ and ‘gitk’ will always be fast.

You only need to push the tag if you’ve tagged a commit that has already been pushed in the repository, otherwise it goes along with the commits with ‘git push’.

‘git rebase’ is important because it makes your local commits in sync with the updated upstream head, ie the local commits are moved forward to start from the new head.

Excellent writeup from our Editor-in-Chief, thanks!

Couple comments:

“git checkout -b new-branch” comes handy. That creates the branch and switches to it.

Instead of git-pull, many of us use git-fetch followed by “git-rebase origin/master”. That ports your changes to the latest upstream development instead of leaving you with one of those useless “merge” commits.

It would be cool to see this on l.g.o, similar to http://live.gnome.org/GitForGnomeDevelopers (which focuses on using git-svn on existing GNOME infrastructure).