Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles Interview with Mike McQuaid about Git in Practice

Interview with Mike McQuaid about Git in Practice

Mike McQuaid's Git in Practice is a hands-on guide that introduces Git from a practical perspective, offering over 60 techniques and commands for working with Git repositories, as well as advanced techniques and workflows for experienced users.

The book is split into four parts, allowing advanced users to jump ahead whilst novices can read through and understand how to work with Git repositories.

The first part provides a basic introduction to Git; how the commands work from a command-line perspective (as well as through a GUI) along with how to host Git repositories and work with remote ones such as GitHub. Readers who are new to Git will be able to get a springboard here which will come into play for understanding later parts.

The second part looks under the hood at how Git repositories work, what that means to working with history and recovery operations. Topics such as merging, stashes, rebasing and reflogs are covered, along with the ways in which Git can manage the history of the repository.

The third part provides an overview of more advanced Git commands; how to configure Git to provide a more useful shell, useful configuration options that can be configured and aliases created along with submodule support. Upgrading a SVN repository to Git is also covered, along with working with GitHub pull requests from the UI and from the command line.

The final part discusses Git workflows, using Mike's experience in involvement in both the Homebrew and CMake projects and the pros and cons associated with each. Whether a continuous deployment/single flattened history or a network of merges is a function of the project's individual working practice. Mike compares these with Git Flow, GitHub Flow, and what he refers to as "Mike Flow". The part concludes with an overview of the different types and recommendations for different types of teams and projects.

The book contains many hands-on techniques and examples, along with a means to create a history suitable for experimentation.

InfoQ caught up with McQuaid to ask him about the book, and started off by asking whether Git is a version control system that can only be used from the command line:

McQuaid: Git is primarily available as a command-line application. That's the interface I focus on in my book and I think it's worth learning if you need to do advanced things with it or are e.g. an experienced software engineer. If you're not working as an engineer, though, I'd probably instead point people to GUI applications like GitHub for Mac, GitHub for Windows, GitX-dev, the GitHub website (which lets you e.g. branch and commit from the site) or plugins for your IDE (e.g. Visual Studio or Eclipse).

InfoQ: Git is a decentralised version control system; does that mean there is no centralised repository?

McQuaid: Git can function as a local-only version control system where it doesn't interact with any other repositories. Additionally, a repository can fetch/pull/clone from remote repositories or push to other remote repositories. That these repositories are not coupled together is what makes Git decentralised but it can function in a centralised fashion too.

If you're working on a team with other engineers and everyone has e.g. write access to a private repository on GitHub then you will typically only have one remote repository (named "origin" by default) and will push and pull to this repository as if it was a centralised repository.

InfoQ: Is it necessary to understand how Git stores repository content under the covers in order to be able to use it?

McQuaid: Definitely not; despite writing Git In Practice I still don't really understand how Git stores repository content! In Git In Practice I try and avoid teaching these things for their own sake. There's some aspects of how Git stores data (e.g. understanding that branches and tags are pointers) which helps understand some of Git's more bizarre messages about e.g. a "detached HEAD pointer" but even this isn't essential.

InfoQ: What advice would you give for people considering migrating from Subversion to Git?

McQuaid: Don't try to map concepts too closely together; they are different tools with different strengths, weaknesses and interfaces. Consider using git-svn or GitHub's Subversion backend for repositories to ensure that you can test migrating people gradually and perhaps allow different groups to migrate at different times. Make sure you learn more than just the basics of Git and don't be afraid to do things like rewrite (local) history so you can make the most of the tool.

InfoQ: People unfamiliar with Git may be concerned that it is possible to rewrite or lose history. Is this a valid concern?

McQuaid: It's possible (and, I'd argue, desirable) in Git to rewrite history. It's almost impossible to lost history. Every time you create a commit in Git it has a unique reference based on its contents and metadata. These references cannot be duplicated and are always valid, even after rewriting history, until they are destroyed. Commits are only destroyed when they have been removed from all branches for at least 90 days and until that time you can use the "git reflog" command to see how and when history was rewritten and recover any old versions of history.

InfoQ: Is Git suitable if projects are managing multiple versions of releases instead of continuous deployment of a single version?

McQuaid: Yep! Git supports branches and tags well and they are far quicker to create and change between than in most version control systems.

InfoQ: What kind of common Git workflow patterns are used by development teams?

McQuaid: The most common two I come across are GitHub Flow and Git Flow (or modified versions of them). GitHub Flow focuses on branching from master, making a pull request and merging back to master as quickly as possible. Git Flow has a more involved process I won't detail here but provides multiple checks before any particular branch ends up in production or a stable release. Personally I find Git Flow overcomplicated which is why I came up with my own version I (stupidly) called Mike Flow.

InfoQ: Can you explain a little bit about Mike Flow, and why you think it might be useful for your readers?

McQuaid: Mike Flow is something I consider a bit of the best of both worlds; it's basically a modified version of GitHub Flow which encourages more rebasing (a form of rewriting history) and only creating long-running branches if stabilisation of releases is required. I go into more detail about it in Git In Practice and compare it to GitHub Flow and Git Flow.

Git in Practice is published by Manning. Save 40% on Git in Practice with discount code infoqgip at

About the Book Author

Mike McQuaid works as a software engineer at GitHub. Outside of that he speaks at conferences and trains people in using Git. He's contributed widely to Git-based open-source software, including Qt and the Linux kernel, and am a maintainer of the Git-based Homebrew project, a popular OSX package manager.

Rate this Article