Is it worth using CLI Git in 2024?

Well, is there an alternative?

Sure, dozens of them! What truly surprised me is that many developers do not know how to use Git from the console – they have only learned to use it through GUIs. You can find excellent GUI implementations, for example, in VS Code or IntelliJ IDEA. In this article, I will compare the VS Code implementation to the traditional CLI.

This VSC looks amazing! Who needs the CLI then?

No one will get hurt by at least giving it a try. In my opinion, it is best to combine both approaches. On a daily basis, I use both the CLI and the VSC GUI. Why, and what for? You can find all the explanations with examples below.

Simplicity

What I truly appreciate about using Git in the CLI is its incredible minimalism. Whether you’re initiating a small project or simply looking to back up or keep track of some data, the task can be accomplished with just a few commands. Additionally, you always begin with a calming, clean, and dark console. There’s no need to launch an IDE or an external application and be confronted with hundreds of options:

With the CLI, you always see only the information you need at any given moment:

Certainly, you do need to learn, understand, and use these commands correctly. However, if you work professionally with code, developing this habit should take only a few weeks.

If we were only considering personal or small projects, we could conclude with a score of 1:0 in favor of the CLI. However, there’s certainly a compelling argument for using integrated Git when collaborating.

For instance, when you’re resolving conflicts during rebasing, which is an everyday activity, doing it from the console requires you to manually remove certain lines, which may not be the most enjoyable thing to do:

And this is what you see in VSC: resolving conflicts in a view like this is almost a pleasure. You get to see the exact differences, and you can accept them with just a single click. Moreover, there’s an indicator showing how many conflicts still need to be resolved:

While writing this article, I came across a tool named “mergetool” that slightly improves the CLI experience:

However, to be honest, I can’t imagine a world without conflict resolution in VSC, and I don’t know anyone who still uses the console for this purpose. The same holds true for displaying the history of more than one branch:

Reliability & Universality

I can’t speak for everyone, but personally, I don’t fully trust the VSC Git panel. I’ve been surprised on numerous occasions: sometimes after staging changes and committing, I found that there were still files waiting on the stage. Other times, it didn’t detect any changes even though the “git status" command showed plenty of them. This might be attributed to the large size of the project, but I have NEVER encountered this issue with the CLI, which is why using it often becomes the only reliable way to achieve your goals.

Consider this: What if someone needs your help, but you’ve been exclusively using Git GUI your entire life? I was once in that situation: as an intern, the advice I received was to install the entire IntelliJ IDE just to access Git tools. While it was a helpful solution at the time because I soon realized how fantastic conflict resolution in a GUI can be, I now believe it’s impractical to be unable to find a solution without the need for additional software installation.

The CLI commands are the same on every device, no matter what. In contrast, each GUI is different. It’s much easier, faster, and less error-prone to simply dictate commands step by step rather than explaining and searching for where to click within a GUI. For more complex tasks, you can easily copy and paste commands, and they will still work as expected. Not to brag, I’ve assisted coworkers and friends numerous times, and each time, I could simply close my eyes and provide a series of commands, request console output, dictate one or two more steps, and voilà, problem solved. Indeed, it’s that simple to keep track of what’s going on while navigating through the CLI. Once, I even managed to do this remotely during a hackathon, using a simple communication tool. And trust me, at 2 AM, after 14 hours of non-stop coding, my mind wasn’t so sharp.

It’s essential to keep in mind that you won’t always have access to a GUI. There will be instances when you need to connect to a server through SSH, for example. In such cases, having a solid command-line knowledge becomes essential.

By the way, none of the developers I’ve assisted have ever heard of “git reflog," which, in my opinion, is worth knowing about.

Speed

You could argue: Okay, the execution of commands in the CLI is naturally faster than in a GUI, as the latter has to continuously display and refresh history, status, branches, etc. (which does depend on your device’s performance and project size). Also, in general typing is faster than clicking. However, you cannot deny that typing a command like “git checkout feature/XYZ-123″ is faster than just clicking this branch in GUI!

You’re mostly right. But I can show you that “gchb 123" is indeed faster. What am I talking about? The good, old bash aliases – the simplest way to automate the most common tasks. Here’s a list of some I’m using:

alias glo="git log –oneline"
alias gll="git pull"
alias gsh="git push"
alias gch="git checkout"
alias gco="git commit"
alias gs="git status"
alias grc="git rebase –continue"
alias gpu="git push –set-upstream origin"
alias gchd="git checkout develop"
alias grd="git rebase develop"alias gconoe="git commit –amend –no-edit"
alias gchb=’function _gchb(){ branch_name="feature/RPA-$1″; echo “checking out to $branch_name"; git checkout “$branch_name"; };_gchb’

This is a game-changer. While it may not be the most efficient method and does require some initial setup time, it’s undoubtedly the simplest and error-free solution that you can easily customize to suit your preferences. You can find a complete list of bash aliases on my repository: https://github.com/Stanlee77/bashSetup.

A valid counter-argument is that in VSC, you also have quick access to Git commands, enhanced by auto-complete and selection lists:

However, with well-prepared aliases, the CLI can be noticeably faster. It’s also worth noting that you can equip your terminal with autocomplete and multi-select capabilities. A prime example of this is the previously mentioned Lazygit. Admittedly, it’s not as straightforward as the out-of-the-box experience in VSC, but it’s certainly achievable.

Extensions

powerful tools to your Git workflow. One such tool, while not necessarily advanced, is Conventional Commits. It helps you maintain a structured commit history by adhering to a specific naming convention:

<modificationType>(<scope>): <emoji> <commitTitle>

For example:

refactor(ui): ♻️ add types

As you’ve likely noticed, all the feature branch commits visible on the screenshots in this article follow this convention:

That’s because it’s an established rule within the RunBotics project. RunBotics is an open-source, rapidly developed application for automating various processes. You can try it out for free without registration right here! Trust me, it’s worth exploring. You have the option to contribute to its development or utilize it for automating both personal and business tasks!

Back to the topic, the necessity of using Conventional Commits prompted me to write commit comments within VSC. There it’s a matter of installing an additional extension. Although, to make it available in the CLI, you’d need to “get your hands dirty”, but I truly believe it’s possible, and I plan to tackle this challenge. If I succeed, I will certainly make it available on my GitHub.

Sea of options

I’ve asked some developers I know for their opinions on this matter, and it seems that most of them prefer the CLI for personal projects while opting for GUIs for larger ones. There are fans of having everything integrated within VSC, and others who prefer to use a separate desktop application. After all, it seems that the great majority of them opt for a mixed approach, utilizing both CLI and GUI as needed.

Final words

To sum up, I’ve compiled the pros and cons of the two approaches below, and it’s clear that there’s no one-size-fits-all winner. Ultimately, the choice between them should be based on your individual preferences, and the specific demands of particular project.

Regardless of the outcome of the comparison and our personal preferences, we can undoubtedly agree that Git itself is a robust and enduring tool that continues to gain in strength with each passing year. It has come to the rescue of many of us on numerous occasions, and its impAortance in the world of software development cannot be overstated.

Author: Stanisław Jarocki, Software Developer