If you are or were a fan of the Atom editor you might have encountered git-plus, one of the most downloaded extensions from their marketplace. I created that extension 5 years ago and it’s been downloaded 2.5 million times. I now work on team productivity tools, but my first passion was making git more accessible and useful to individual developers.

For anyone not familiar with git (I assume that means almost nobody who works as a developer), git is a distributed version-control system for tracking changes in source code during software development. It is designed for tracking changes in sets of files which makes it great for coordinating work among programmers. Its goals include speed,data integrity, and support for distributed, non-linear workflows.

What git is great at

Undoing Mistakes

We all make mistakes. Some of them are costly and others are minor. Git provides a lot of support to recover from mistakes. Commits can be undone, erased, re-ordered, or even melded together.

Maintaining History

Git can store an impressive amount of metadata about a repository. For example, the official linux repo on GitHub has almost 850,000 commits since April 2005, which is also the same month git was initially released and the repository was created from the linux team’s previous source control system. Being able to reference the history of a repository is very important if you need to understand how and why changes happened (although the “why” depends largely on the quantity and quality of the commit messages).

Experimentation

Git has the concept of branches, which is a big differentiator from most other version control systems. Branches allow us to try different approaches with the codebase without affecting the “main" branch or the releasable version of code and this is so useful because it enables concurrent development.

What git is not so great at

User Experience

The user experience isn’t always intuitive because some tasks can be accomplished in many different ways with varying combinations of commands. And because git was created as a command line utility, that’s the primary interface and those who don’t live in their terminal have to interrupt their workflow to context switch into the terminal and execute git tasks. Because this context switching can be so costly and intrusive, many editors have plugins or built in features for at least simple git execution. It is this poor user experience that partially inspired the birth of git-plus.
How git-plus came to be
Although I initially created git-plus for fun, it quickly became useful to other people. In the same day of the initial release, I had issues opened in my GitHub repo about minor installation problems and people would state their excitement and eagerness to use it. In the following weeks, as other users requested new features, I was adding them mostly because I thought I was also meeting my own needs. I then realized I had built something that really resonated with other developers.

The package was quickly moving up the popularity list and I was receiving emails from people sharing their gratitude and even offering me money! I was blown away and satisfied knowing I had built something of value. As git-plus got more popular, free and paid video tutorials were developed by third parties. Today, git-plus has a healthy user base, contributions from 63 other people, and has inspired other git and productivity packages for the Atom editor. Someone even found the project interesting enough to create a really neat video visualizing the commit information of the source code over a 1.5 year period. Pretty cool!

When VS Code was first released, there were many requests to create git-plus for it. At the time I was not a user of VS Code, so I did not take than on. Still, I was willing to support anyone who wanted to initiate the project. I am now a part-time user of VS Code, and I now work at CodeStream with Eric Amodio, the creator of GitLens, and we share stories about our plugins.

One plugin I had a fantastic experience with is vim-fugitive and when I first got my invite to use the Atom editor back in the alpha stage, I was shocked that there wasn’t already a built-in way to execute even the most fundamental and common git operations like staging and committing files. So I decided to build one (git-plus) as a fun project. I wanted user friendly abstractions for the common git operations. Git-plus has commands like Add all and commit, which will stage all modified files and initiate a commit, and there’s another version of it that will also immediately push the changes once the commit is done. Many of these multi-step tasks that we often execute multiple times a day have been turned into simple commands that can be bound to a keystroke. Beyond those commands, there are ways to inspect the git history. Git-plus can show commit logs for an entire repo or just for a specific file, display details of the commits, and show diffs between branches (both local and remote).

Being able to create, access, and consume git info with a few clicks or keystrokes generally saves time. The dirty details of how the data is created or accessed generally don’t matter for the average user's productivity as long as the task is accomplished. I’ve spoken to developers who don’t like tools like git-plus because they say these tools don’t teach people git. My response to comments like this is “They are not supposed to” and that is exactly what makes the tools so useful. They don’t bog us down with the gory details of how git works and they enable us to do what we need to do and move on. That said, those details can be interesting and in the process of creating this package, I had to learn more about git, which I do enjoy and recommend any git users to do. What I learned in building git-plus, helped shape my views on productivity going forward.
Development team productivity is the next frontier
Developer productivity is important, not only to me personally because I take pride in reducing the effort needed to develop elegant software, but also to millions of developers and the businesses they help build. Virtually everybody writing software uses a version control system of some sort and git today is the most common. Using git can be great, and when properly supplemented, can lead to productivity improvements.

Sharing Knowledge Widely

As I expanded my efforts towards improving developer productivity I worked on various tools related to development workflow in different contexts. I realized that the next step in improving productivity would not focus on individual developers, but on team dynamics and knowledge sharing. Helping development teams become more productive is now my full time job.

Today, I’m helping build CodeStream, another plug-in (with multi-IDE support) that leverages git and other technologies to enable real-time discussions about code in-editor. The goal is to allow developers to shorten the time between question and answer, issue and resolution, by simplifying communication about code. We are helping them move their code conversations, which are generally taking place in Slack, Microsoft Teams, email or GitHub to the place where they can be easier and more natural, and ultimately most useful: right next to the code itself.

Because these conversations live with the code, we can use git metadata to link the conversations to specific files, code blocks, and repos so developers aren’t context switching yet again to discuss their codebase or to glean information about it. With CodeStream, finding information about the history of code becomes unnecessary because it highlights in your buffer the specific code that is being discussed. In this way, we can turn the external conversations we have today into ergonomic and accessible documentation.

Summary

Hopefully these tools I’ve mentioned continue to be useful to developers and maybe even inspire more ways to better improve developer experience and productivity. My journey with git-plus was both fun and useful, and it taught me much about software development needs, processes and flows. I hope to have as much impact with my current project. Moving towards developing for teams is proving interesting and challenging. I will be happy to connect and discuss this with anyone who feels this work is important and impactful.