Pitfalls and Lessons Learned when switching from SVN to Git

This is not Git howto, it just describes where our team had trouble when starting our current project in Git.

Git is not SVN

Just forget everything you know about SVN. Start over with a fresh mind. Ok checking out and commiting are still similar, but when working with branches and tags, it's a whole new world.
Take a look at the Git cheatsheet: https://Git.wiki.kernel.org/index.php/GitCheatSheet

Don't get confused by the many commands, you'll get there. Starting Git is not that complicated.

Play around

You don't need much give Git a spin. Install it, work with it in a local repository. There is plenty of information out which will show you how to do so. Try everything you need to do in your daily work life. Merge, branch, tag .....
The only important thing is: work on the command line. After you got everything figured out you can use your IDE as an aide.

Watch out, branches

Here's the first thing i stumbled on. I was working on two branches, both not too different. Let's call the brA and brB.
So after creating to files in brA, I switch to brB to test something. I was wondering, why brB did have the same files and modifications I just did in brA.
Long story short. Never switch away from a dirty state, unless you know what you're doing.
What happened? Before switching away from brA, I had my repo in a "dirty state". That means, I had changes I did not commit to my working tree. These files will "follow" me to whereever I go.
This is actually very useful, if you want to test if a fix or change you made works in different scenarios before you commit it. But sometimes you do not want this behavior. So there are two options to avoid it. If you're sure you want the code in the branch, commit it. Otherwise stash it. There's a nice post to stashing on ariejan's site.

Mastering your branches

The next idea i had to learn is how to deal with branches and the master. So in our environment we support one version of the product, which is on the market. This versions has its own branch and tags. The master is the recent cutting edge version with all the features. So if there's a bugfix in the current release, you have to make sure, that the release is fixed and the change makes its way into the master.
There are to ways to do so. The one i like more is to go to the branch, do the fix and then cherry pick or merge the change to the master. Cherry picking is very useful if you can do the fix in one commit. If not, merging is the better choice. Of course you can also go the other way. Fix it in the master. But then make sure you cherry pick it into the branch, otherwise, when you merge, you will end up having new features in your branch.

Pushing and Pulling

As Git is a distributed version system, all your committing is done locally. So if you want to "store" your changes in a remote repo, you have to push them. It's a good idea to have a common master, in which every developer pushes and pulls her changes. The extra kick is, you can use different locations to push and pull code. So if you feel you want to get some changes from a fork somebody else is hosting somewhere (maybe Github?) you can provide a destinations for the operations.

Setting up Architecture

There's not much you need. But a central repo is a good idea. As I'm a big fan of JIRA, you can use the JIRA Git plugin. Another option is Gitosis, especially if you use it as an addon. It runs well with redmine, so user creation and permissions can be done via the web. Git is getting so big, almost every Bugtracking/Codetracking site has a plugin for it.

Personal Conclusion

We are working with Git for about 8 weeks now. I do not want to go back to subversion. Especially if your team is more than two people sitting next to each other. Code control is so much easier with Git.