Why developers should prioritize learning git from the command-line.

Photo by Raphael Nogueira on Unsplash

As a software developer, it’s important to know your tools. When it comes to source-control, git is the most common source-control repository out there in open source by a very large margin as of the time of this writing. I would say it’s very likely the most common for closed-source as well.

That said, in this time where increasingly-intuitive GUI applications are available for working with a git repo, why would anybody want to use the archaic or arcane CLI?

Reasons to use the command-line

1) Learning the CLI gives insight into what the GUI is doing

When using git from a GUI you’re using an application that is simply using the git CLI commands under the hood. By knowing the nuances of what commands the GUI is executing on your behalf, you’re going to be far more informed of the effects of your actions.

2) Cross-platform compatibility and consistency

Whether you’re on Linux, Windows, or Mac and developing in Eclipse, Visual Studio, VS Code, or a generic text editor each environment is going to have its own git tools available. Some of these are IDE integrations and some are standalone tools. What happens when you switch OS or IDE? What happens when you go to help a friend and they don’t have the same tool installed?

The thing is, any of these tools (to my knowledge and experience) are going to have the foundation of having the git CLI installed as a prerequisite. That means, you will always have the CLI as an option.

A big point for this is in a terminal-only environment where a GUI application simply isn’t an option. Being able to still utilize gitproperly in an environment where you’ve SSH’d into is a good skill to have.

3) Speed of development

All of these points are my opinion and I will admit, this third point is probably the most subjective of all. That said, when I go to use git I find it far faster to type git pull in the CLI than hunting down some sort of fetch/sync option. I can do this by having a separate terminal open, or having a terminal open in my IDE.

Something as simple as a git pull may not be a very convincing. Consider instead a more complex scenario where I’ve got active code and perhaps a coworker has merged some changes and I need to pull in his changes, branch, commit, and push up a branch to create a PR. Such a series of commands may be:

git stash
git pull
git checkout -b features/123-fix-bug-x
git stash pop
git commit -am "Added fix for issue# 123 resolving race condition"
git push -u origin features/123-fix-bug-x

In an extension or interface, that sequence of actions probably would’ve taken several dialogs, buttons, and checkboxes. Yet, from the CLI it can be accomplished in sequence without leaving the single window.

Again, I acknowledge last point is very subjective and even the example given isn’t fool-proof as there could be things like conflicts but there are many cases where simply knowing the few commands you’ll commonly need will simplify a process.

You can view my write-up on the most common git commands here.

What I commonly bypass the command-line for

There are times where it’s easier to skip the CLI. The biggest differentiator is where the CLI is simply inefficient in displaying the data that is needed.

1) Conflict-editing

There are typically far better ways of editing conflicts than terminal-based text-editing.

2) Large or Initial commits

This comes into play where there a lot of files in multiple folders where I may not be 100% certain that the .gitignore is fully fleshed-out yet. The need to skip the CLI is common for example on an initial commit to ensure any log files or build-related folders aren’t accidentally committed.

Additionally, the CLI does not show the full structure of un-staged folders. If git add . is used which is the easiest way to stage a large amount of new files it can then pick up a file you didn’t intend and have to un-stage the file(s). This can be tedious when it’s multiple files or a whole subsection of a folder tree.