Where do we go after Git?

Let’s get this party started

Preamble

Git has redefined the way we write software. It’s an ingenious technology, and its community and ecosystem are utterly vibrant. It’s become so ubiquitous that it’s hard to imagine anything could follow it. But that line of thought should sound suspicious by now: People said the same thing about the horse and buggy, the gas lamp, and the landline telephone. Humans are fundamentally a restlessly inventive species, and technology doesn’t sit still. So, while Git might still feel fresh — perhaps due to everything flourishing around it — it’s worth remembering that the first version was released two years before the original iPhone. A lot has changed since then, to say the least.

To be clear, this is not a piece about Git’s imminent demise. I love Git, I don’t think it’s hit its limits just yet, and I don’t think it will go away anytime soon. It will probably continue growing for the foreseeable future, and it will likely never go away entirely. Perhaps someday, after a lull in use, there will even be a Git Renaissance, reminiscent of the return of vinyl. But something will come after Git, and it seems time to start guessing what that might be.

Let’s first travel back in time for a moment. Git’s embrace of distributed workflows mirrored the decentralization of computing in general that was underway. No longer did power reside solely on a central server, with clients playing only a dependent, subservient role. The endpoints could pull their own weight, and the result was a newly mobile, newly free world. This was truly liberating!

However, new problems arose: Most painfully, that data was out of sync — or entirely unavailable — across devices. If it’s difficult to remember quite what that was like, consider that Git was released the same year Microsoft purchased FolderShare, thus entering the “emerging space of file synchronization and remote access technology that helps customers access information across multiple devices”. It was a year before Google Docs, and two years before Dropbox. This is the world Git was born into.

Needless to say, it’s not the world we live in anymore. The technology landscape continued to shift, with especially enormous changes in the ways all these computing devices connected to each other. As digital communications got faster, richer, and more reliable, not only could every device handle its own bit crunching, but all the devices could work together, effectively in real-time. The idea of information on one computer being different from the information on another computer began its slow, inevitable dissolution. And this gives us our first hint where version control goes after Git.

Predictions

Since the development of Git reflected the movements in computing a decade ago, we might suspect its successor will reflect the transformations we’re living through today. As such, we might expect to see some of these:

Connected by default

Git makes it trivial to associate a branch on your machine with a branch on a remote device. But by default these associations are just pointers, not connections. Unless you manually fetch updates, or use a Git client that does this periodically for you, the data on your machine gets stale — even if all the devices are networked. To any modern technology user, this should feel remarkably outdated. If someone else is working on the same thing I am, I expect to be told without having to ask.

Always moving

Git’s lightweight branching model makes it easy to quickly step aside and try out some changes, without fear of really messing things up. You can commit your changes in your own branch, ensuring they aren’t lost, and only merge them back if things work out. But there are still plenty of opportunities to lose work: If the power goes out with unsaved changes, or if you decide you need to get back to a state between commits, you’re likely out of luck. These days, I trust software to never lose my work, no matter if or when I thought to save. My work is always in motion, and I expect my software to keep up.

Socially present

Git’s commit model lets me know who’s done what, and when — but only in retrospect. While we’re doing work on our respective machines, none of us know what each other is doing, even if we’re working in the same file. Nowadays, if I’m editing a file at the same time as someone else, I expect my editor to tell me that — and to tell me precisely where in the file the other person is, too. The wild success of GitHub proves the goodness of layering social workflows on top of source control, but it’s about time we started baking that sociality in.

Party

Those aspects describe something rather different from Git. More than a source control management system, something that’s connected, in motion, and social sounds a lot like… a party. So let’s get this party started. What follows is a hypothesis for the future of software source control.

$ party start myhouse @friend1 @friend2

To get things going, we start a party called myhouse and invite two of my friends. This sets up the equivalent of a Git repository on my machine and on my default central server, and sends notifications to friend1 and friend2.

$ party talk app.js

We begin to talk with each other to work on some core logic. As we edit, we all see each other’s keystrokes and insertion points in real time. This is normally where we’d be saving, committing, pulling, and pushing in Git — but none of that happens here. Everyone is partying together.

$ party punchline "Basic logic works"

Eventually we reach a stable point. Even though every action we’ve taken so far has been automatically remembered, some points in the timeline are certainly worth remembering more than others. For that purpose, we call out a punchline, which represents a point in time of interest. These are convenient references to use in the future, similar to tags in Git.

$ party clique refactoring @friend1

Eventually, friend1 and I decide we need to make some risky changes to the logic, and we’d prefer to not interrupt friend2’s work. I create a clique called refactoring and invite friend1. Although friend2 will have real-time view access to everything happening in the refactoring clique, only friend1 will be invited to edit. Because cliques serve to isolate sets of work, they’re similar to topic branches in Git.

$ party listen center

Friend2 is still working in the center of the party, the equivalent of the master branch in Git. By default, when I created the refactoring clique, friend1 and I stopped seeing any work that friend2 was doing, which let us focus on our own work. But after making the most significant changes, we want to keep up with what friend2 is doing again, so we can resolve any conflicting changes. We listen in to the center of the party, and are instantly caught up with friend2’s work. This is similar to fetching remote commits and merging them locally in Git.

$ party join center

Once we’ve worked through a few merge conflicts and gotten everything in a good state, we join the center of the party again, at which point friend2 sees our work. This corresponds to pushing work back to a remote master in Git, except that friend2 doesn’t then take the manual step of fetching those changes.

$ party rewind 2min

At this point, friend2 finishes up a couple things, then looks through our work. Most of what we did is just fine, but it turns out we deleted something they planned to use. So friend2 decides to rewind the party by a couple minutes to find that code we removed.

$ party bring app.js:112–114

They identify that they want lines 112 through 114, and they bring those lines back to the present point in the party.

$ party punchline "Full logic implemented"

With that taken care of, we then mark another punchline indicating the status we’ve reached.

$ party replay start

Before wrapping things up, we replay our work from the beginning — sped up quite a bit, of course. Because the party stored every action we took, it’s able to play back our activity since we began.

$ party end

Everything looks good, so we end the editing session and call it a night.

Postscript

A successor to Git may or may not come anytime soon. It may or may not look anything like what I described here. And it may or may not ultimately take the world by storm quite like Git has. But why wait to find out? Someone has to make it happen — will it be you? If it is, please be sure to invite me to the party.