Pragmatic version control using Git

Written by Travis Swicegood published by The Pragmatic Bookshelf, 2008, ISBN-13: 978-1-934356-15-9

At 184 pages this is a short book on Git, but it does cover the bare necessities and then some. Apart form 3 appendices the information is added in 11 chapters:

  1. Version control the Git way
  2. Setting up Git
  3. Creating your first project
  4. Adding and committing: Git basics
  5. Understanding and using branches
  6. Working with Git’s history
  7. Working with remote repositories
  8. Organizing your repository
  9. Beyond the basics
  10. Migrating to Git
  11. Running a Git server with Gitosis

While Git is more complex than the book can explain - and it doesn’t try to explain everything, it is pragmatic after all - I would say it covers the Pareto 80% of the standard user’s needs.

Following the Pragmatic tenor the book does the job of demystifying Git without attacking Subversion or CVS - or any of the other distributed version control systems. Chapter 10 handles the issue of migrating from SVN or CVS (via SVN) to Git.

As a side note to this, I would add that I think filesystems are stupid in the sense that they ought to have changed to transaction based systems at the time disk space was sufficient for this kind of storage, and that the ’save’ button in every application ought to simply do something akin to a Git commit. IMHO the snapshot way we currently use is simply stupid.

While there are some nifty tricks you can do with Git with regards to the history I think it should be mentioned that these tricks are better left only for your personal branches and not for a shared commit. That is, it is okay to modify the order and squashing branches before you push or allow others to pull.

It’s kind of funny that the single biggest benefit of using Git - as I see it - is the personal revision control, and that isn’t mentioned in greater terms, though Travis does mention the benefit when he was working with a Subversion repo - see the box “Being the Git: Using Git in a Subversion Company” on page 141.

I would have liked to have seen some recommended workflows for different setups as well as some developer discipline guides, i.e. branch before you do anything new, have a working solution you’d like to be able to return to? Commit! Even after a working unit test.

The book is a fast and okay-to-good read.

Comments are closed.