I quite often hear experienced Git users say that you should always use the command line for Git, and you should try to avoid using Git GUIs. Whilst I understand the reasons given, I also think it's a huge generalization that unfairly sees Git GUI users as unlikely to really understand Git properly. I certainly know Git very well, and honestly think I'm far faster and more efficient in a Git GUI than I could possibly be on the command line - and I'm certainly not slow in the CLI.
So this post is here to play devil's advocate, and argue against the CLI for your primary Git usage. In a very light-hearted and friendly way of course! Do remember that the term Devil's Advocate is all about making a point just to make people think about both sides of the argument more ...
Someone who pretends, in an argument or discussion, to be against an idea or plan that a lot of people support, in order to make people discuss and consider it in more detail
Although, in all honesty - I'm not pretending, I do genuinely think the GUI is a better fit - but, I enjoy using both! This post is to make people think more about which is actually more productive.
First of all, I want to point out that I am a big fan of the CLI, and use it very heavily in my daily workflow. I quite often have a second monitor dedicated to ConEmu, with multiple split console screens. So this post is certainly not coming from someone who's anti-CLI. I thought this was an important point to make before I begin, so you know that I'm not just someone who's generally biased towards GUIs.
So if I'm such a fan of the CLI - why do I not think it's a good fit for source control? Well, source control is actually extremely visual! You're looking at logs, commit graphs, diffs, and much much more. A GUI is far better suited to this. Let's take this screenshot as an example ...
This is the log view from my preferred Git Client SmartGit. The points I make in this post apply to most other GUIs too though.
As you can see from the screenshot - without even typing anything - I can immediately look at the screen and see: branch information, commit history, commit details of the selected commit, the list of files in that selected commit, a file diff of the selected file in the selected commit, what branches the selected commit is in, etc, etc. I haven't even typed anything yet either. Imagine what you'd have to have typed to get all that information on the CLI.
Then when I want to actually do something, most of my workflow is very keyboard shortcut driven. So rather than typing git fetch
, git rebase
, git log
, git push
, etc, etc - I'm instead literally just hitting keyboard shortcut combinations. When I watch someone use Git via the CLI - I see an awful lot of typing to achieve what I get by just mashing a couple of hotkey combos. Doing it on the CLI might look cooler, but it certainly isn't faster - even when the CLI user uses aliases.
Whilst performing these actions via keyboard shortcuts - the view in the screenshot above automatically updates without me having to do anything. So I'm always seeing the latest data. I don't have to keep on typing git log
all the time.
There's also plenty of other benefits - eg. if I want to compare two different commits - regardless of whether they're on the same branch or not - I can just select the two commit, holding down the control
key to multi-select, and you can immediately see the differences. Likewise when diffing or doing a three-way merge - this is far easier to visualize in a GUI.
The main argument I tend to hear against using GUIs, is that developers do not understand the commands that are being run on their behalf. And this is most certainly true for some developers, and yes, it really isn't good! However, I do think this really is an over generalization towards Git GUI users. I imagine this comes from the fact that the type of person who is a heavy CLI user, is also the type of person who gets to know their tools properly - therefore most CLI users do actually grok Git. However, that does not mean that most GUI users do not grok Git. It just means that most people who don't grok Git, tend to be GUI users. GUIs aren't to blame for their lack of understanding though - it's just that people who aren't willing to learn Git properly are also very unlikely to be willing to learn the CLI - hence creating a very biased dataset.
Another point about using the CLI, which I do agree with - is that in some scenarios, you'll only have a CLI and may need to use Git. Eg, if you're SSHing into a Linux box. This is a very valid point, and I certainly agree that GUI Git users should also be comfortable with Git on the CLI. Whilst I mostly use the GUI, I do switch to the CLI from time to time for a bit of variation, and make sure I'm still fluent in using the Git command line. I'm certainly not saying you should never use, or not know how to use, the CLI.
Whilst this post may well provide me with lots of hate mail - it is actually only meant light heartedly. When it comes down to it - you can hot-swap between the CLI, and multiple GUIs to your heart's content - it's all Git under the hood. Therefore I do recommend you do this often and get used to lots of different GUIs as well as the CLI. As always with technology - learn, tinker, play - be curious about what's going on and have a deep desire to fully understand the tools you use. This applies regardless of whether you primarily use the CLI, or if you use GUIs.
Please retweet if you enjoyed this post ...
Blogged: "Git - GUI vs CLI - The Devil's Advocate" https://t.co/JVXdL5XoI5 #git pic.twitter.com/jxVJCFuYsE
— Dan Clarke (@dracan) October 8, 2017