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
I am using VS 2017 Team Explorer for staging, committing and syncing. For the detailed and complex things TortoiseGit, no problems here. Its just a huge time saver and using a GUI does not mean a lack of understanding.
And im a frequent linux user who really likes consoles to work.
I'd use the analogy of learning photography: you start with a manual analog camera, shooting black & white, and once you've grasped the theory, you upgrade to colour and eventually digital. Those little burn and dodge tools in Photoshop make a lot more sense when you've actually burned or dodged with your hand or a stick in a darkroom.
I used git for years in the command line, and once some nice GUIs came out, it was like a breath of fresh air. Being able to visualise trees, changes, and diffs is a huge boon to many developers I know. But, as with photography, it's important to understand the underlying theory behind each button you press.
Should a knowledgable developer stick to CLI-only git? Not in my opinion. Should you start there? Absolutely.
I think this idea can be married to the IDE vs non-IDE "debate" very well. Understanding every tool you use at a fundamental level is a high aspiration and something that will make you a very powerful developer. Not understanding the tool (or what the tool helps with) completely, where you cannot function well without it, is not a situation where you should be ashamed or an feel like an impostor developer. Nor should it be dictated that using without understanding it fully is doing anything by "coincidence." That's absurd. Use the tools you can use to get your desired end-product. If you can't get the desired end-product with your tools and current knowledge, then it's time to invest a bit more in your knowledge.
The GUI version of Git abstracts away a lot of finer details that, frankly, most of us don't know, don't care to know, and don't need to know. Not saying that a broader understanding isn't useful, but it's not required. Understanding Git enough to use it at the command-line level is just one of the next steps you can take in expanding your craft. For some, it might not matter as you will never manage your own version control, while others it will be essential.
I agree. I use Tower on occasion to look at file diffs or clean up branches, but I use the git CLI (and some custom aliases/bash functions) to manage projects/files.
I find this is a lot easier, and when there's an error, I don't get a cryptic popup from a GUI that's playing telephone with the actual commands and responses it runs; I get hands-on, first-hand messages from the source.
Though this comfort comes from a few years' time working from the Terminal; if we were talking about the file system– CLI vs GUI– I would go with CLI as well.
I'm youngest developer on our team and to be honest, never tried anything but GUI for git till last year.
I decided to actually KNOW what am I doing ... so, switched to Linux and started doing it by command line.
Heck, now they all come to me when they have problem using git