In the introductory video for Getting Git I talk about using Git from the command line instead of through a GUI. I label GUIs as evil wizards and slay them with a custom die command.
But why? What's wrong with GUIs?
I didn't randomly label GUIs as evil wizards. This term comes from one of the first and still top programming books I've ever read – The Pragmatic Programmer.
The Pragmatic Programmer is filled with stories to highlight everyday scenarios you'll encounter as a programmer. Most of the stories end with a Tip. The book contains over 100 tips.
In this case, I'll reference Tip 50:
Don't use wizard code you don't understand
This tip results from Section 35: Evil Wizards and can be applied to the command line versus GUI debate. Since a GUI is generating Git commands on our behalf it classifies as a wizard.
So the question becomes, what's wrong with using a wizard?
I've adapted the following passage from the section:
unless you actually understand the commands that have been produced on your behalf, you're fooling yourself. You're programming by coincidence... If the commands they produce aren't quite right, or if circumstances change and you need to adapt the commands, you're on your own.
I think this hits the main point. You have to actually understand Git. As programmers, it's a tool we use every day. One that has a very small set of commands - around 15, less than half of which you'll use frequently.
In the end, the problem isn't with the GUI, it's with a lack of understanding. I'll use a GUI for visual diffs or as a merge tool. But, I'm also comfortable viewing diffs and resolving merge conflicts from the command line.
If you're using a GUI for Git, I encourage you to challenge yourself. As you're using it, try to identify the underlying commands used to generate the current screen. If you can't, you're using an evil wizard.
Want to be more comfortable using Git from the command line? Getting Git contains over 40 videos covering Git commands from the command line as well as scenarios you'll encounter using Git every day.
Latest comments (40)
Anyone know the git cmd that shows me the three most recent other branches I have edits on?
git branch --sort=-committerdateWe use Git at work. We used to always have weird merge situations, gibberish commit trees, lots of conflicts, and I had to troubleshoot someone in the team at least thrice per week.
Until the day I read this guide. I understood what branches really are, what these strange “HEAD”, “origin/feature/mystuff” were, and why some people in our team were actually merging their work with out-of-date head references without knowing it.
Of course a good GUI can show how to solve your issue. It’s what I used for troubleshooting and fixing stuff easily. It just doesn’t explain it, and since we learned how Git actually works without blindly relying on GUI buttons, our issues magically disappeared, as well as the need to troubleshoot.
It appears that the author found a lot of traction about this topic, but automatically disregards other people's reasons for using GUIs and the advantages that come with it.
I, for one, started by purely using GUI. At that period, my usage of Git was basic, and GUI was perfect for this. Eventually, as my understanding of Git improved, I got to the comfort level where I can utilize command line to do more advanced manipulation. GUI is not sufficient anymore.
I still use GUI, though. For me, not an absolute exclusive keyboard user, it is much more easier to execute
git guiand use my mouse to see all the changes that are pending to be committed. If you like to use several keyboard commands to do the same, you can have it your way, sure.But don't tell me I should not use GUI because it is evil. That's one of the sillier statements I've read.
Calling yourself a master of git does not improve your picture either.
As the author, I'm curious where you read the statement you "should not use GUI because it is evil".
C'mon, you know there are so many better ways to make the same point.
What an insightful contribute… Allow me to contribute by reporting your comment.
I think newbies should use a GUI instead of a command line. A GUI is much more discoverable, and the command line just encourages XKCD 1597 style uses.
Let's say A and B are new to git, and discovered they had one change that should have been on their last commit. Now, seasoned git users would be saying that
git commit --amendis the obvious answer, and they're right. However, A and B just recently switched from Subversion, so they don't know that Git has an amend function.A is using the command line, so they just make another commit using the same
git add . && git commit && git pushspell they've been reciting. Why would they read the docs when they think they know the solution already?B is using a GUI, and notices that on the commit dialog there's a checkbox that says "amend last commit". The feature is right there discoverable and not hidden among the infinite possibilities of flags.
Now I do argue that a better shell can change a lot of this. Perhaps when you start typing
git commit, it pops up a list of available, or at least commonly used, flags, akin to an IDE.What about when you need agility? I understand your point, but if you aren't capable to do things faster then you loose opportunities. Some times you need allies to reach your goals. GUI clients may be good tools for improve your process.
Initially, I found that having a GUI allowed me to become more confident with the basic Git workflow, even after reading through the basic functions of the CLI and having a fair amount of experience utilizing other command-line tools. Though, after using Git for a few years now I can't even remember the last time I used a GUI.
Nevertheless, I agree that learning Git using a GUI, with no knowledge of the CLI could definitely lead to issues and hinder productivity down the line.
I'm using both my IDE (where I can see what commands it executes for each GUI action/shortcut I use) and for some things like interactive rebase/squashing I'm using command line.
If you have a GUI you understand and like you are still not bound to it.
What about this tool, which simplifies opening repo in browser from terminal?
github.com/plutov/o
I like
git openbetter - github.com/paulirish/git-openIt's good! But
otool works for different git hostings :)So does
git open.I agree if you don't understand what is happening behind the scenes, then you'll easily get lost and confused. I mean I like hooking Git up to my text editor or IDE, but I always start with the CLI