I think this question is just a special case of “Why should I learn any CLI for which a GUI alternative exist?”. I suspect the latter question is about as old as GUIs, and I assume there were many attempts to answer it over the years.
I could try to bumble my way through my own answer to this question, but Neal Stephenson articulated what I agree with as the ‘ultimate answer’ more than ten years ago in his remarkable essay In the Beginning… Was the Command Line.

While the essay touches on many aspects of computing, and while even Stephenson himself thinks that a lot of it is now obsolete, the essay explains in what ways CLIs are better GUIs in an extremely compelling manner that literally changed my life. It’s a long read (~40 pages), but I can’t recommend it enough to anyone who asks questions like you asked here.

Finally, though I’d answer any CLI vs GUI sort of question in similar vein, I think my answer holds especially true to your specific question since of all computer things you chose to ask about git. git is arguably the latest tool in a not-so-long list of computer tools that are truly worthy of the hole-hawg metaphor as described in Stephenson’s essay. git, like several other Unix-ish things, is a reason to know CLIs all in itself. Sometimes in spite of its erratic ‘porcelain’; sometimes because of it.

So yes, you can definitely be productive with github’s GUI, either for OSX or even just on their website. Yes, it’s actually quite sleek, I use the features of the site often. But no, you will never have that Godly feeling as your right pinky hangs above an insane git filter-branch command for an aeon or two. If I had to keep just one thing from my experience with computing – the mental challenges, the close friendships formed in a datcenter at 2AM, the infinite ladder of competence to climb, touching users’ lives and reigning over PBs of precious data, the cushy jobs and comfortable life – keep just one thing – it’d be that Godly feeling.

If all your needs are covered, awesome, no need to dig deeper into git, your time would be better spent in learning something you actually need.

git is just a tool, when you’ll need to do something you can’t with a GUI app, you’ll know it. Just keep in mind that github != git.

Most of the CLI-only features only come into play when you accidentally get your repository into a weird state and want to fix it. On the other hand, the most common way to get your repo into a weird state is to use advanced features you don’t understand. If you stick to what the GUI provides, that will cover your needs 99% of the time.

The other reason you may want to learn the CLI is that it is git’s lingua franca. That means while a lot of people use different GUIs on different platforms, if you ask for help on StackOverflow or elsewhere, the answer is most likely going to come in the form of CLI commands. If you don’t know the CLI, your options for obtaining help are going to be much more limited.

GUI applications rely on manual interactions to perform complex behaviors. This is great for setting up projects and developing new things.

The benefits of a Command-Line Interface (CLI) come from the ability to create predetermined scripts that can be automated. All GitHub’s GUI is, is some nice graphics and fancy buttons that call the git CLI.

What the GUI app won’t do for you is automatically update a repo’s trunk on a server daily at 1:30 AM, but a cron job that calls the git CLI is a really easy way to set that up.

Additionally, when working on a project in a team, it’s convenient to set up install scripts, build scripts, deploy scripts, and the like so that teammates can focus on solving problems instead of tedious repetitious tasks.

Another reason why the CLI might be preferable is a matter of workflow. Many frameworks are managed through the command line. Using git through the CLI let me stay focused on my project and in that project directory. For instance I might run a test and then decide to commit the new changes all from the same interface and location.

I recently have to really dig into Git to be able to help with an SVN-to-Git migration. And the thing I learned is that the Git command line tools are not the complicated part to learn.

The concepts and ideas behind Git are the complex part (and that’s not because they are badly designed, but simply because they are foreign to most people who come from some other, centralized VCS).

Once I’ve grasped the concepts, the actual command line statements became relatively easy. That means that a UI doesn’t really help understand Git (except for the simplest operations).

Knowing the CLI comes in handy for when (not if) you’re in some environment where you can’t get at a GUI app.

One potential scenario: You’re asked to help out for just a couple days on a project in a closed location where it’s annoyingly hard and long to get new tools into the system. They only use CLI. Your productivity just took a hit because you need to learn everything all over again.

One reason to learn command-line git is that most documentation is written for that environment. Also, if you ask a question: “how do I do X with git?”, chances are the answer will contain command-line commands.

One of the main problems with using a GUI versus the command line is that you are unable to have the same control over your process, in most cases. For instance, the GitHub application is great in terms of usability for a lot of git workflows, but could still be cumbersome for advanced git processes.

As an example, here are some things that I have not figured out how to do using the GitHub application (another thing to note is that each GUI also has a learning curve).

• Rebasing commits
• Push/Pull/Fetch individually (in GitHub they are grouped into a single “sync” command which might cause problems some times)
• Amending commits

Finally, CLIs allow for users to use these tools when scripting.

I don’t know about GitHub for Mac, but the Windows app only perform the most common tasks — add, commit, push, pull, etc. More complex tasks like git merge --no-ff have to be performed from command line.

Also, there are cases with git when GUI is not available, e.g. when SSHing into remote servers.

But otherwise, if GUI gives you everything you need then learning command line may be a waste of time. My work uses TortoiseSVN in Windows-only environment, and I have not had to touch SVN command line even once.

I just learned one case in which CLI can be better than GUI. To illustrate this, I took an example from a book git – version control for everyone.

When you want to share over an intranet, then you can use:

1. Gitolite server
2. Common share directory with bare repositories

Look at the steps for creating a bare repo.

Creating a bare repository in CLI mode

The command for creating a bare repository would be the same as the one that you used to
clone a repository except for the –bare parameter, which makes all the difference.
git clone --bare C:Usersraviepic3DesktopWorkbench C:generic_share
Bare_Workbench
Executing the preceding code in your console should create a bare clone of our Workbench repository in your common shared folder called generic_share .

Creating a bare repository in GUI mode

Creating a bare clone from an already existing repository using GUI is an easy process. All you need to do is:

1. Copy the .git directory from the existing repository and paste it with a different_name.git (whatever name you want to give to your new bare repository) outside the repository. In our case we have a non bare repo called Workbench at C:Usersraviepic3Desktop inside which we have content.docx . And now I want to create a new bare repository from this using GUI. I’ll copy C:Usersraviepic3DesktopWorkbench.git and paste it as C:generic_shareBare_Workbench.git .

2. Open the config file inside Bare_Workbench.git with a text editor and find the
   line which says bare = false and replace the string false with true .

3. Save and exit.

In GUI, you have to do so many clicks and remember which file is to be edited. In CLI, one simple command does it all for you.