Git for teachers

It’s all fun and games until you hit a merge conflict

Git is a source code version control system very tightly bound to development practices. Unlike most of its predecessors, it allows developers to work in a truly decentralized way: you branch a copy of a codebase off into your own area, then develop and test.

GitHub is more than a pretty UI on top of git. One of the functional layers it adds is called a Pull Request, which allows you to submit the code in your branch back to the original codebase’s owner. They can request changes, reject it entirely, or merge your code in. This mechanism is why GitHub has become the go-to site for open source projects: project owners can accept submissions in a carefully structured way. (It also works within closed teams, which often mandate that everyone submits their code through a pull request, so that other team members can review it.)

For software, it’s transformational, but I don’t really understand why educators are trying to make this work for other things.

Which isn’t to say that you shouldn’t. Some of the best things on the internet have come out of people using a tool for something other than its intended purpose. Nonetheless, it’s worth considering these shortcomings:

Git doesn’t work well without the command line. Apps are available, but they only cover a subset of the functionality, and I’ll inevitably find myself on the console. Developers spend half their lives on a bash prompt. In a lot of ways it’s like using a computer in 1989. There shouldn’t be a need for anyone else to subject themselves to this.

Git works on a line-by-line basis. The currency of git is the diff: a record of what’s changed across all the files in the codebase. Rather then operating on a character-by-character basis, if you change one thing on a line, git will mark the whole line as having changed. If you indent a section of text, the whole section of text will be marked as changed, even if none of the content has.

It’s for plain text. Sure, you can check in a binary file like an image. But git won’t track individual changes to the image; it’ll just track that the image has changed in some way. Ditto a Word document, or anything else you can imagine. It’s not nuanced enough to intelligently deal with bodies of text.

You can’t make it friendly. For newbies to source code, let alone decentralized source control, there’s too much to get to grips with. It’s a completely different way of working designed for a different industry.

So what else is out there?

Sadly, Poetica just closed its doors, in order to become part of Condé Nast. Its vision was “GitHub for poets”, and combined the underlying mechanics of something like git with the kinds of shorthands editors have been using for decades. Penflip might be the closest tool in its absence, although it’s dependent on markdown. I tend to think markdown is unintuitive and unpleasant to use in itself.

The problem with both — and the nice thing about git, in contrast — is that commercial startups have a hard time becoming infrastructure. Git wouldn’t have succeeded as a startup; the web wouldn’t, either. This kind of infrastructure really needs to just be there for anyone to use.

On the other hand, GitHub has become incredibly successful as a separate company, based on proprietary code that builds on git. So here’s what I think needs to exist, but doesn’t:

1. An open source, freely-available content control tool designed for people working with non-code. It’s okay for it to not know about fancy file formats like Word, but it should be able to handle more than line-by-line changes. Perhaps call it scribe.
2. A proprietary, beautiful city ecosystem built around it. A ScribeHub.

Git surged in popularity once GitHub was created. At the time, tools like Mercurial were also vying for developer attention, but GitHub was so well-executed (and pull requests were so vital and obvious) that it sealed the deal. Similarly, an open source tool like scribe could be used anywhere, but ScribeHub would add the network layer that could allow you to find and manage collaborations far more easily. This balance is where open source can really work.

This seems like something there should be funding for: a way to bring the networked collaboration of git and the network effects of GitHub to a non-technical, academic audience. Academics trying to shoehorn git to fit their practices shows there’s a need.