When we started working on GitButler a little over a year ago, we were trying to make sure we were working on the right things. If we want to make a great new user interface for Git, it would be nice to know how people are using it today and what they think could be better.

We of course know how we use Git and what we're frustrated with, but we wanted to make sure the zeitgeist was not way off of our intuition.

So, since we wanted to have a waiting list, we used it to ask people some questions trying to qualitatively get an idea of what the world of Git is like these days. Since we're now in open beta and our waiting list is no more, we thought it would be interesting to share the data from the last year of people answering our questions about Git.

We asked the following questions:

• What do you use now as a Git client?
• Would you be OK backing up your working directory to our servers?
• What is frustrating about how you use Git or version control today?
• If you could hire a great intern to just handle your git/version control/github tasks for you, what would you have them do?

In the year that we had the waiting list live, we had 1253 responses. Here is what we found.

The first interesting thing to us was how people use Git today. Are they mostly on the command line? Are they mostly using GUIs? Our intuition is that most people are still using the CLI because it's faster to get stuff done, but we weren't sure.

We had a multi select field (you could choose more than one) that allowed you to choose CLI, built in editor tool, standalone GUI or other.

Here are the top responses. The "other" category was about 2% of responses and fell into GUI/TUI/Editor, so those each might be another 1% higher. We also had a fill-in-the-blank option for "other", so we have 50 or so individual responses like "Gitui", etc, but not enough to move the data much so I didn't try classifying them.

However, it's quite clear that most people still use the command line.

Some use a combination, mostly CLI and editor. Our guess would be that a lot of people use the GUI for more complicated things like patch staging, but it's difficult to know exactly.

What's most interesting to us here is that very few people are using a GUI exclusively. Although 30% say they're using a Git GUI, only 8% are only using a Git GUI, everyone else combined it with another response.

This is interesting to us because we're looking to provide server based tools at some point and want to know what the general population's comfort level is with source code going to a third party.

Looking back on it, I probably shouldn't have mixed up "Maybe" and "Some", but we can just combine them if you don't care about the nuance.

About 20% of people are fine with their code going to a third party and about 20% absolutely can't. The rest could, but it depends on the circumstances or the code.

The next two questions are much more subjective, and were free form, so it's a little more difficult for us to quantify them exactly. However, it's very interesting to see what the general themes are.

The first question was about what people find frustrating with Git, the other is related but from a different angle, which is about if you had an intern that just focused on this, what would you have them do?

We wanted to know which things people want to entirely offload from their VCS workflow, versus which things they just want to be easier or faster to do.

First we have responses about what people don't love about Git, or maybe what they think could be easier.

We spent a good amount of time reading a large sample of the responses and coming up with some main classifications that we heard over and over. After classifying everything into zero, one or more of these major themes, this is the general distribution of what people find frustrating about Git today:

Let's go through the important ones.

Complexity and Usability

Approximately 20% of our users complained about usability or complexity of the commands. One in five felt that obscure Git command syntax and the resulting steep learning curve were barriers to efficient use.

Some quotes from our hundreds of responses in this area:

• "There’s a half dozen commands I use every day/week. And then… suddenly there’s a need to reach for one of the lesser used commands."
• "Git can be complex and difficult to grasp for beginners. Understanding its concepts and commands, such as branching, merging, and rebasing, can be challenging."
• "git diff, git rebase, git bisect, git patch, git cherry-pick are all very powerful but not very convenient to use."
• "I always have to look up the commands, a lot of 'common sense use cases' need a lot of research to be done if you are not an expert."

Approximately 30% of our survey identified frustrations with Git around how to manage your branches or commits. This includes things like issues with undoing or modifying commits, writing meaningful commit messages, and navigating project history.

Branch management was a theme of 20% of users, with comments like:

• "Working on several branches in parallel can be tricky."
• "Stashing changes when switching branches. A lot of this has been "solved" to some extend by using bare repos and git worktrees, but it still doesn't feel quite right yet."
• "chains of branch dependencies"

Commit management was another 15% of users (some percentage overlapped with frustrations in both). Here are a few examples of comments in this category:

• "Remembering to make atomic commits."
• "Creating beautiful commit messages and cherry picking changes can be time-consuming."
• "Wide variation in usefulness of context provided in commit messages. Long run history loses context due to external link bitrot over time."
• "Having to look up how to undo add/commits."

About 13% of our responses mentioned frustration with merge or rebase conflict resolution. This makes sense, as it's a rather common issue that everyone runs into and there isn't a great way of dealing with these yet.

Some example quotes were:

• "Things that should be easy are complicated, resolving conflicts, reverting merges..."
• "Merging, reverting, cleaning up mistakes :)"
• "Merge conflicts and branches that depend on one another."
• "Most of the tools for dealing with merge conflicts suck"
• "Merge conflicts and more specific commands (have to look up every time – but I'm also a beginner)."

Collaboration and Code Review Process

Another 11% of our users discussed challenges in collaboration, particularly around code reviews and coordinating work within teams.

Some choice quotes:

• "Code review relies on third party tools/UI."
• "Getting teammates to agree about when to rebase, squash and things like this."
• "No visibility and downstream effects of code changes."
• "Coordinate work with other teammates."
• "Editing and restructuring commits (after development is complete) so that they're easy to review"

Rebasing and Rewriting History

The last significant group was that about 8% of our survey mentioned difficulties with rebasing or otherwise rewriting history, with examples like these:

• "Hard to correct mistakes from rebasing, cherry picking etc"
• "Rebasing multiple branches that depend on each other"
• "Lack of visual support for interactive rebasing."
• "Having to rebase to separate out independent stacked changes into separate branches"

Overall, it's a little difficult to get good objective classifications of open form data like this, but after looking at hundreds and hundreds of these responses, it's fairly clear that these are the big categories that large parts of the Git user community finds difficult.

The other subjective open ended question was interesting for us from the standpoint of what we might want to work on as features in a new, smart Git client.

I like the idea of trying to imagine that you have a competent intern who you can just offload certain tasks to. It means that you want them done, but you feel that you personally have more important things to do or that they're not the hardest part of your job perhaps.

Here we had a number of themes around more tedious things that a lot of software developers find that they would like to outsource to someone else. For GitButler, these learnings are quite interesting from the point of view of determining strong future roadmap candidates.

Commit Management and Cleanup

The biggest thing that people want help with is having a great commit history. There are hundreds of these types of responses.

• "Probably don’t need an intern, just the motivation to be regularly committing (or write a script that does it). I used to be much much better at lots of atomic commits. Then I worked somewhere that seems to have conditioned it out of me, and I’ve not brought it back :/"
• "Go through all my changes and commit things in logical order with clear points to revert to if needed"
• "Organize my work in a way that I understand the reasoning behind every change, so that later I don't have to rethink again."
• "Rebase all my stuff before merging to create beautiful commits with meaningful commit messages"

People want to have a commit history that looks like the Linux kernel, but it's so much work that most people simply don't do it. Almost a quarter (22%) of our responses had some version of this.

How great would it be if you could just work and someone else went through and organized and explained your work in a series of beautiful commit messages?

The next biggest theme of outsourcing work is around managing branches and contexts of work. More than 17% (1/6) of our responses had some variation of this theme in them.

• "Regularly delete my local branches that have already been merged into main."
• "Create and manage dozens of branches. My code is both interdependent and long-lived – it doesn't fit nicely into the "create a branch, implement a feature, merge" paradigm. It's more of a "create 17 branches that all depend on each other and none of which can really be merged for the next 2 months" type situation."
• "Keep tabs on my in-progress work that I want to experiment with, but isn't ready for a PR yet."
• "Make sure to keep me straight on not committing everything to my current branch and remind me I can make others"

People just want to work and not have to remember what goes where or is related to what. Creating, deleting and switching branches is a large theme of what people don't want to live without, but find at least a little tedious to manage.

There's no point pulling quotes out of the responses, there are just dozens and dozens and dozens of these:

Nobody wants to deal with merge conflicts and everyone has to deal with them all the time.

We definitely have some big ideas on how to approach this problem set in GitButler in a very different way, so it's great to see that people really want more help in this area.

There are a surprising number of comments around doing Pull Request management. Even though it's not really a Git thing per-se, it's clearly a large part of people's Git-related workflows.

Over 8% of our responses want someone to help them manage PRs on GitHub.

• "Write PR descriptions for me"
• "Not really outsourcable, but let's assume that intern had enough context to be able to do this - i'd have them write meaningful PR descriptions for changes, so that I lose as little time as possible in the grunt work required to foster a multi-person development process."
• "The whole PR process."
• "Fix merge requests"
• "Break up changes into PRs"

We also got feedback on code review and testing in general (4%), documentation (4%) and help with deployments and CI (3%), but the big ones were on branches, commits and merges.

Overall, the big takeaways for us are that a lot of people still use the Git command line tools and that there are still issues with a lot of the core functionality that people need to do every day, especially around commit crafting, branch management and merge conflicts.

We're excited to tackle these problems in new and interesting ways at GitButler, but either way, it's pretty interesting to see what the state of the art of Git is in 2024.