I think there are a number of great things to learn from the git UX.
- sub commands (and sub sub commands) provide a high level abstraction over the many different tools and features. The "toolkit" approach allows for easy expansion and refactoring of individual features, and is entirely pluggable by end users. It even provides tools to interface seamlessly (git rev-parse --parseopt; rev-parse is amazing and allows you to wrangle git types trivially). Git also doesn't care what language you use. It ships git subcommands in C, shell and perl, but you can use node, python, bash, go, whatever you like. Really great.
- git divides it's interface and features into porcelain (user facing) and plumbing (internal; used by porcelain implementations). This allows them to avoid breaking changes while providing new and exciting features. This is a great design choice and it's been copied extensively by many projects, but I've never seen it pulled off as well as git.
- git consistently reuses terms and objects (there have been some missteps over the years but the maintainers are very humble). Commit objects, refs, dates and times all work the same almost everywhere.
- git is extremely well documented, both in its man pages, online and within the tool itself. Help flags and interactive messages and descriptions and suggestions of what to do next. Have you ever performed an interactive rebase? Or resolved a merge commit? Or corrected a tracking branch? Just great stuff.
I know we love to hate on git here but let's just for a moment acknowledge this wonderful, powerful tool for something it does a great job at. Git cuts no corners, it's consistent and trustworthy, and a hallmark of modern day software engineering and UX.
> Help flags and interactive messages and descriptions and suggestions of what to do next. Have you ever performed an interactive rebase? Or resolved a merge commit? Or corrected a tracking branch?
Yes to all. Then I showed it to people new to git. And saw them fail week after week. They got into states they didn't expect, didn't understand, and didn't see expected feedback. Clever people who needed to blow away the repo to get to a known state in the easiest way. The most common problem was making a new commit in the middle of a rebase, and accidental committing or blowing away conflicts on pull. Next was switching the branch during an interactive operation and basically ending up with unknown state.
You listed many things which make git powerful, but a good ux is something different. It requires good, consistent context, clear boundaries between expected and unexpected operations (why can you checkout during rebase, for example?), and discoverability. If you interact with enough developers, you'll get asked "what do I do? I don't know what just happened" - and that's the mark of bad ux.
Good UX doesn't mean holding your hand. I think Vim has pretty great UX -- it's been my daily $EDITOR for years. Is there a steep learning curve? Sure.
Often with tools like Vim, Git, etc. there is a dependency on the end user taking the time to learn, absorb and understand the documentation for the tool.
> It requires good, consistent context, clear boundaries between expected and unexpected operations (why can you checkout during rebase, for example?), and discoverability.
I think git really excels here. Why wouldn't you want to be able to checkout during a rebase?
To me, UX is ultimately about the long tail -- if I am using this tool for a hundred hours a week, am I helped or hindered by it? For too many tools society embraces, it's the latter.
UX and HCI is about so much more than just sitting an untrained person in front of a keyboard.
That's not why programs come with documentation. Documentation helps, but being intuitive in usage is something completely different. Intuitive means you can either do the simplest operations without reading the docs, or that you can figure it out as you go from the context clues. Git does neither. You need to learn about the model, the operations, the repo / staging / checkout / remote areas to complete the most trivial "modify-commit-push" workflow.
Sad to see this in the grey. Git is unintuitive to those who don't understand it. If you read about its internals and learn how it works, the command line gets much better. It's well documented and it gives you a whole lot of power and insight into the inner workings of the VCS. Things like launching your editor to do more complex commands, plugging a script into git bisect, these are all great design choices.
It didn't matter how powerful it is. It's still inconsistent and a bad example of ux. Some trivial examples: "tag -d", but "remote remove"; exiting editor after "commit" aborts, but after "rebase -i" continues operation; etc.
There are other projects that interact with git and are really good: tig, for example. But git itself? Someone wrote a good paper about it already. "What's wrong with git?" was the title, I believe.
All of what you say is correct. git is great in many ways and not too difficult to use once you grok the internals.
But git's user interface is inconsistent, has got weird error messages and confusing terminology with too many ways to do some things.
Good thing that it has quite decent manpages which explain these things thoroughly. The UI gets the job done but it sure isn't a great example of a well designed command line.
It's rough in some ways, and elegant in others. A bad error message does not a bad UX make. Good error messages are great, but remember UX is also about hitting the important points well.
I question this study's sample size and diversity.
Git was made by and made for kernel hackers to support the Linux kernel. It has an expectation that the user understands how their computer works and wants a tool catered to that knowledge. The average web developer writing Ruby or Node in Atom on their Macbook Pro isn't in the target audienece. For someone in git's target audienece, it's a great tool with far better UX than any other VCS - because it gets out of your way and gives you powerful tools for mucking with the VCS to suit your needs precisely. THIS is what makes for a good UX. A tool that's easy to learn is great, but if it can't be mastered and bent to the user's will then I'd rather take one that's hard to learn but accomodating of the master.
> The average web developer writing Ruby or Node in Atom on their Macbook Pro
It does not matter who it was designed for, git is the de-facto VCS that almost everyone uses today. And people are having trouble using it because there is no better alternative: it is fast and powerful and used by many companies.
But it's UX is terrible: I use git for 10 years and I have to Google every time I need to make a branch tracking a remote one. git reset does different things based on what type of object you pass.
This has nothing to do with knowing how internals work, it is a question of consistency and providing a small non-overlapping set of tools to do my job.
>It does not matter who it was designed for, git is the de-facto VCS that almost everyone uses today. And people are having trouble using it because there is no better alternative: it is fast and powerful and used by many companies.
It _does_ matter who it's designed for. If someone outside the target audience uses it, then it's not the tools fault for not accomodating them. My point is that the UX is great for those it's meant to be great for.
>I use git for 10 years and I have to Google every time I need to make a branch tracking a remote one.
git has a terrible UI, IMO. git reset, for instance, does like 17 different things. And what does checkout have to do with creating branches as in "git checkout -b"? Not that git branch is that much better, it's conflating creating, listing and deleting under one command (named after a verb or singular noun). Compare to hg's branch/branches or fossil's even clearer convention of noun + action, like in "fossil branch new ...".
That said, you are right that understanding the git model helps a lot and for that, I recommend the "Getting Git" talk. https://vimeo.com/14629850
I enjoy how much git-flow-avh dumbs down git for me. I've been using regular old git commands for years but inevitably end up in some weird merge conflict with myself and possibly a slightly inebriated version of me that was coding the night before.
I'm using git cli.
Already tried sourceTree, gitkraken, intellij plugins, atom plugins.... all these attempts ended up in "I do not know which branch I am in" or "How do I get a diff to remote"?
Agreed, part of why I love the integrated terminal in VS Code... mostly doing git, node and npm commands while working on my projects. About the most GUI I use, is the active diff tool in VS Code. But that's not CLI based. I've also tried a few gui tools for git, and none seem to be quite as easy as just using the CLI for it.
Probably the cli that I find the most useful beyond git that I use regularly is docker... It's pretty useful if you aren't in a linux environment but need to build something in one... In my node lambda builds, I'll do something like:
docker -i -v "${PWD}/dist":/app -w /app node:6.10 npm i
Which is usually enough to give me something I can zip and upload for use in a lambda... Though, like git, if I'm doing something not usual, I often wind up having to google it. Like anything in git more complicated than a simple rebase or add/commit/push.