What Git Got Right and Wrong
Even though I understand what is going on behind the scenes, I find Git to be an unintuitive mess at the CLI level. However, there are a few things it's gotten right.
Join the DZone community and get the full member experience.Join For Free
I've been using various version control system (VCS) solutions for a while, so I think that it is worth noting that my least favorite from a user experience perspective is Git. To be sure, Git has better handling of whitespace-only merge conflicts and a few other major features than any other VCS solutions that I have used.
- The DAG structure is nice.
- Recursive merges are good.
- The data models and what goes on behind the scenes are solid.
- It is the most full-featured VCS I have worked with.
However, I still have real complaints with the software. These include fundamentally different concepts merged into the same label and the fact that commands may do many different things depending on how you call them. The fact that the concepts are not clear means that it is worse than a learning curve issue. One cannot have a good grasp of what Git is doing behind the scenes because this is not always clear. In particular:
- In what world is a fast-forward a kind of merge?
- Is there any command you can explain (besides clone) in three sentences or less?
- What does "git checkout" do? Why does it depend on what you check out? Can you expect an intermediate user to understand what to expect if you have staged changes on a file when you try to check out a copy of that file from another revision?
- What does "git reset" do from a user perspective? Is there any way a beginner can understand that from reading the documentation?
- Git commands try to do too much at once and this is often very confusing.
- Submodules are an afterthought and not well-supported across the entire toolchain (why does git-archive not have an option to recurse into submodules?)
These specific complaints come from what I see as a lack of clarity regarding what concepts mean and they indicate that those who wrote the tools did so at a time when the concepts were still not entirely clear in their own minds. In essence, it is not that things are named in unclear ways, but that the concepts have unclear boundaries.
Some of this could be fixed in Git. Fast-forward could be referred to as a shortcut to avoid a merge rather than a kind of merge. Some could be fixed with better documentation (we could describe "git reset" by what the user-facing changes are rather than the internal changes). However, some would require a very different set of command layouts.
Published at DZone with permission of Chris Travers, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.