Skip to main content
\( \newcommand{\lt}{<} \newcommand{\gt}{>} \newcommand{\amp}{&} \)

Chapter3With a Few Friends

One of the real benefits of git is the ability to collaborate easily with others in a de-centralized manner across time and space. In this chapter we will experiment with a model that is appropriate for a small group of collegial collaborators. My dictionary (WordNet) defines “collegial” as “characterized by or having authority vested equally among colleagues,” which is precisely the situation we will simulate. So, in this chapter we will explore the scenario where a small group of equals works on a writing project, on the assumption that everyone in the group is trusted to make any sort of change at any time.

We will not be using email attachments or Google Docs to communicate. Rather, an easy way to collaborate with git is to place a copy of the repository on a server where each collaborator has the right privileges to interact with the repository. If your project is secret and sensitive, this might be a server at your workplace, or a web host you control and trust. Or maybe the project is not so sensitive and a private account at GitHub is appropriate and easy to set-up. Or maybe your project has an open license and an open repository will eventually allow total strangers to contribute to your project (see Chapter 4). For exercises in this chapter, we will use GitHub, a (free) site that hosts git repositories along with tools supporting collaboration around a git repository.

Notice that Alice and Bob only had to communicate about whose account to use for hosting the paper and on decisions about content. Never did one have to wait on the other, nor did they pass around files with version numbers. And since Alice pushed her recommendations to the definitive repository first, it became Bob's responsibility to edit a conflict locally before he could push his idea of how the recommendations should go.

To summarize, the drill is always the same. Edit locally on a branch, update your master by pulling from master at the definitive repository, rebase your branch on master, while resolving any conflicts, merge your branch into master (fast-forward), push master to the definitive repository. We call this the Eight-Step 1 and you can find a general version in our quick-reference appendix, Appendix C.

There is just one more general git concept left, the pull request, so continue on to Chapter 4 to see how to open up your collaborations to the long tail of contributors from the entire world.