Why This Book I recently had some close friends talk about their hesitation in adopting Git as opposed to continuing to work with Subversion. I’ve used Subversion for many years, and advocated for its use. I have since jumped wholeheartedly on the Git bandwagon, so I wanted to find a way to tell the story of why I made the switch and why I think so much of the open source community is now based around Git and Git-friendly sites like GitHub.

Setting up Git I’m not going to spend a lot of time talking about installing Git. The audience for this book is familiar with installing software and using a command line, and Git is sufficiently available on various operating systems that I’ll just assume that git --version on the command line doesn’t return command not found. I’m also going to assume UNIX syntax for other commands. I’m also not going to talk about GUIs.

Multiple Repositories In Subversion, the only way we work with multiple repositories is through a mirror, which has to have exactly the same history to work correctly. Git is designed around multiple repositories; to help work on a project, you have to have not just a working copy but a “clone” of the whole repository so you can commit, push, and pull. Like Subversion, a lot of teams using Git share a common repository located on some server.

Teamwork Of course, we could continue working like the previous chapter. Harry or Isabelle makes a change, pushes it, the other pulls it, and everyone is kept up to date. But in a real environment, Harry and Isabelle are going to be making changes at the same time. Starting from the scratch directory again: cd harry echo "Third content" > content03 git add . git commit -m "Third" And meanwhile…

A Conflict This time, Harry and Isabelle both decide to add a line at the end of the same file. Starting from the scratch directory again: cd harry echo "Harry's line" >> content01 git commit -am "Harry" git push Notice that I added an a in front of the m in the git commit command. Because I’m not adding any new files, only updating modified files, and I know it’s safe to pick up all my changes in the commit, I can skip the separate git add step.

Yes, the chapter title puns seem to be getting worse as we go. Not really something I’m in control of. What Are Branches For One of the things I love about Subversion compared to other systems I’ve used is how easy it is to branch. I’ve used version control systems where “branching” occurs at the item level, which isn’t really a branch at all. The way Subversion is architected internally, a branch is cheap because it’s a shallow copy of the repository state at a point in time.

I was under self-imposed pressure to make a chapter title pun, so of course I couldn’t think of one. Better Feature Branches There are a couple of flaws with what we did last time with feature branches. First, one of the benefits of version control is collaboration with others, but Harry selfishly kept his branch to himself and only shared his changes when he was done. Second, while Harry could commit changes to his feature branch, it only lived in his repository, which means if his computer died, his work would be gone.

Feature Branches with Conflicts Straight to the Git this time. First let’s make sure we’re clean. cd harry git checkout master git pull cd ../isabelle git checkout master git pull Isabelle has some work to do and makes a feature branch. git checkout -b hamlet echo "Nymph, in your orisons. Be all my sins remember'd" > spear03 git add . git commit -m "Hamlet and Ophelia" git push --set-upstream origin hamlet And meanwhile Harry is working too.

When It Goes Wrong When I started learning Subversion, it didn’t take long before I had to perform that familiar Google search to find out how to “undo” a commit. The general answer for Subversion is that it’s possible, but it’s far easier to just fix whatever is wrong and make a new commit. That’s very good advice for Git as well. It’s easy to get hung up trying to find a clever Git solution.

What Did I Just Do? The one consistent thing about mistakes is that realization happens about 100ms too late. Whether it’s committing to the wrong branch, merging to the wrong branch, or some other problem, “messing up” your repository is the worst feeling. The most important thing with Git is when this happens, don’t panic, and don’t push. Anything can be fixed, but it’ll be fixed a lot easier if it hasn’t been pushed yet.

Workflow with Git I’ve presented a lot of topics around using Git on a project. I’ve advocated for the use of feature branches. What’s left is to talk about how to get started using Git on a typical project, including both tools and workflow. Tools I mentioned at the beginning that I wouldn’t talk about setting up shared repositories on a server, because that kind of thing is best handled in a GitHub-like tool.

This book was written because I thought there weren’t enough books and webpages about Git. No, not really. This book was written because I saw an ever-so-narrow niche for a book that introduced Git from the perspective of a person who uses it every day, but still remembers what it was like getting up to speed. I remember having questions like: I see that there’s extra complexity with Git because of the need to synchronize different repositories.

Thanks to the individuals who have contributed to this book. Version 1.0: Initial version. Merged in fixes provided by ceilfors and gliptak. Version 1.1: Changes to chapters 2-5 as suggested by a reader. Thanks for the detailed comments. Version 1.1a: Also update the EPUB and MOBI versions. About | Start Reading | Table of Contents