At work we mainly use Subversion for version control. For what it does, it works fairly well.
But everyone else has been using git for ages (GitHub is hugely popular, and projects like Drupal have also made the switch). Added to that: the few times I’ve tried branching in SVN, the ensuing merges ruined my day — completely.
So I decided to learn git, for professional work (superior branching/merging) and for personal stuff (working with Drupal and GitHub code, among others).
I started at home, archiving my
/home/flo/data/ documents in git and syncing it on multiple computers.
Next, I made the jump in a big way at work: I’m now using
git-svn for new projects. So I’m using git, while also still publishing the commits to (remote) SVN.
For using this workflow and still knowing what you’re doing, you need to advance fairly high on the git learning curve:
- adding and committing (obviously)
- stashing changes
- merging branches
- rebasing branches
So far, so good: working with
git-svn is going quite smooth.
It turns out git’s merging is nice, but the interactive rebasing (rewording, reordering and squashing commits) before publication is even nicer.
Online resource I’ve appreciated along the way:
- Hg Init, to un-learn the limitations of Subversion
- Read it twice if you suffer from CVS, Visual SourceSafe or worse symptoms!
- The Git Parable by Tom Preston-Werner
- Conceptually explains why it’s a good idea to have full-history commits.
- New artisans’ Git from the Bottom up
- Explains the hashes, trees and blobs that Git is built on.
- It’s only a pity that this detailed technical approach is given up halfway through the document, where the usual high-level “let’s-draw-some-trees” approach takes over.
- Some nice rants (not always correct though): Steveko 10 things I have about Git, Reinvigorated programmer Git is a Harrier Jump Jet