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.
Oldest comments (40)
I deleted my previous comment, but since a cache is keeping it around, I should apologize for making a point that I missed when originally reading your article!
Whoops, sorry about that. Will fix. 😳
No problem :)
FWIW I started out with SourceTree, which I enjoyed a lot and let me get to know Git in a surrounding I was familiar with (meaning GUI). After switching to Linux and being at a loss of a good GUI client, I went to the command line. That was much easier than expected, because I already knew what I wanted to do, so I only had to learn one new thing (commands) instead of two (commands and Git).
It often pays off to sooner or later go down to the bare metal, especially for tools you use a lot. But I disagree with the general idea that this is always better for everyone. Getting started on a high level of abstraction and moving your way down the stack over time and when needed is a valid approach IMHO. (Same can be said for IDEs, for example.)
I came here to say the same thing :D
For me I always felt (and still feel about Github) like I'm never quite sure what I'm about to do, but at the same time that also applies to my ability to un-do anything the GUI does by accident.
I thought Git was hard until I used it on the command-line, since then it's the only thing I use for Git. The text-based interface is very flexible, and since working with it goes a little slower (you have to enter commands individually) it seems to reduce errors and make solving errors that happen easier. With a GUI for Git it's too easy to do 5 or 10 wrong things at once :/
Challenging my self into using the command line actually forced me to understand git better.
When using a GUI, you can always blame your problems on it, but not when you're using the command line, you're accountable for every command you write, and that makes the difference.
One of the problem with Git (to be fair, it is a common problem to many matters in the programming world, since we all are so smart and all are so right all the time... but I feel this is even stronger when it gets to Git), is that it allows to do many things in many different ways, none of which are right nor wrong.
And since GUIs basically offer a layer over git, the GUI-user is bound to the said GUI's biases. One has to live with the way the GUI-maker feels Git.
Some GUIs try to make a smooth transition by using language from the SVN world and the illusion one is working under the SVN paradigms... but then; what does it mean when in such a GUI there is an "update" button? does it pull? does it fetch? or does it stash->pull->pop(merge) to keep it more SVNy ?
What does the checkout button do? why is it asking me for an URL when I want to switch branches? oh; I must use the dropdown down there ... you don't change branches with buttons...
Anyway, none the the mentioned examples are completely wrong when you know what you are doing and the problem is that GUIs tend to be used by newcomers.
Indeed strangely enough, GUIs might be more suited towards Git gurus who know all about it ... but then again, the said gurus are likely to prefer command line to have all the switches even the most obscure ones.
The only in-between solution might be a GUI that generates git commands on-the-fly and always offers the possibility to view what one is about to run and the possibility to modify it (a bit like SQL developer is doing when creating Oracle users or creating tables through wizard).
My GUI has a button at the top that lets you open a command line. If it's easier to do something in command line, the button's always right there for you. In no way am I "bound" to the GUI. I very rarely find myself using it except for running cleanup aliases though.
I stuck to a Git GUI for a number of years, but recently switched over to the command line, and I gotta tell you, I wish I'd done it sooner.
I was able to get things done in the GUI (SourceTree, GitKraken, and others,) but I had constant merge conflicts, and otherwise got myself into difficult corners, over and over and over again.
Moving to the command line allowed me to understand what I was doing to a far greater extent, and it was actually surprisingly easy.
Anyway, I'm glad I took that step. I haven't boxed myself into one of those nasty Git corners since I gave up the GUI habit.
I dont agree with you, Iam used the command line 5 years but switched to smartgit 1 year ago. To understand git you should not use a gui, but if you already did there is no reason to do it not. Iam just to lazy to do all the things that does smartgit for me by hand.
We might be closer than you think. Your statement of:
Is in perfect agreement with my points.
I would argue the exact opposite. The commands are not the important part of git -- the understanding of how the tree is shaped and how the child/parent relationship works is. That is a lot easier understood visually than textually.
If you are simply memorizing commands, you're not utilizing git to its potential.
You're extrapolating too far. The commands are indeed not the important part of Git, understanding how Git works is important. We're in perfect agreement.
This article suggests a GUI may abstract this and deprive someone just starting out with Git the chance to learn as much as they may from the command line.
There may be some availability bias here since you're already comfortable from Git. I also have a firm grasp on Git and use a GUI for some of the more visual aspects of Git (tree differences, code review, etc). Nothing wrong with that.
In the end, if the only way you know Git is by pressing some buttons in a GUI, then you don't really know Git. I encourage those to try and use the command line to drive their understanding of Git.
I would be curious to see some evidence that implies people who use the command line understand git more than those who use GUI. I think this a bad assumption.
I think it's a case (and there are many others) of there being great value in learning the basics and understanding them before taking the short cut.
I'm confident that I understand git better than most people and I highly suggest people use a GUI instead of command line. Git is visual. You simply can't work efficiently from the command line. If you doubt that, we should do a comparison sometime.
Bold statement. How did you come to reach your confident understand of Git?
I should rephrase: You simply can't work AS efficiently from the command line than from a good GUI. By nature, git is visual because it's a tree structure. And I came to that conclusion by comparing my workflow with other peoples' workflows.
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
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 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'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 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 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
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.