Given that GitHub provides GUI apps for both Mac and Windows, what are the benefits of learning to use git from the command line?

Currently I'm using their mac app to update my repositories, and so far it seems to cover my needs. What might I be missing out on?

  • 15
    Don't forget gitk which is a gui for Linux. Commented Nov 2, 2012 at 3:32
  • 14
    You're missing all the scripting.
    – SK-logic
    Commented Nov 2, 2012 at 14:06
  • 3
    @KChaloux, yes, there is a very good reason why most of the GUI apps are not scriptable at all. And those that are scriptable are just awful (think COM and similar abominations).
    – SK-logic
    Commented Nov 2, 2012 at 14:08
  • 2
    @KChaloux, no the reason is not a quality. It is really hard to make a pure GUI application scriptable. All the reasonable approaches I know are, basically, built upon introducing some form of a command line interface - either a Unix-style CLI, or a text-based command language, or some binary protocol which is essentially the same thing as a command language, see COM. But the best approach, of course, is to have a common core which is both accessible via various CLI tools and from GUIs. The latter can also be built upon CLI for simplicity.
    – SK-logic
    Commented Nov 2, 2012 at 14:37
  • 13
    You don't. In the same way you don't need to learn HTML/CSS because Dreamweaver and Frontpage (or whatever it is now) exist. Maybe it'll work for you for some things, but when it doesn't someone better know how it really works.
    – DorkRawk
    Commented Nov 2, 2012 at 17:37

11 Answers 11


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.

  • 5
    More accessible link to In the Beginning... Was the Command Line: pauillac.inria.fr/~weis/info/commandline.html Commented Nov 2, 2012 at 17:14
  • 1
    Re: obsolete: that'd be the "BeOS as Batmobile" part, right?
    – naught101
    Commented Nov 4, 2012 at 0:58
  • 2
    Garrett Birkel has updated the essay "In the Beginning... Was the Command Line" by interspersing his comments with Neal Stephenson's original essay. You can read about it here. Commented Feb 11, 2014 at 19:34
  • 2
    ...yeah, who needs a CLI when you can create a GUI interface using Visual Basic. Great for things like tracking an IP address.
    – Hey
    Commented Jan 25, 2015 at 10:31
  • 3
    I wasn't suggesting 'older is better', I was suggesting CLIs are (for many hacker usecases) superior to GUIs. CLIs are also superior to binary switches and patch cords. Which is why I use CLIs. The article isn't "proof" because it's "in an article", it's prose with arguments that articulate what I like about CLIs. It's old, but so is UNIX, so what. By the way, I work for Google, and the overwhelming majority of developers around me use a CLI based development environment (but I can't speak for Google as a whole, of course). Commented Jan 25, 2015 at 12:02

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.

  • 1
    I agree with you, but there might be things that I am not aware of currently, that might be useful to me if I were aware of them. No?
    – histelheim
    Commented Nov 2, 2012 at 2:52
  • 29
    @AronLindberg Yes, there probably are. But you are asking the wrong question, what you should spend time investigating is git's workflows and concepts, not it's command line. Even if someone lists you all the functionality the GUI apps are missing, how would you know if you actually need it? (also that's something you can very easily do yourself, just by looking at git's documentation)
    – yannis
    Commented Nov 2, 2012 at 2:55
  • // , A CLI will force you to think about the workflows and concepts a bit more, because all of the organization, choices, and flow will happen in your head, not in Wizards and drop-down menus. Commented Nov 6, 2018 at 21:58

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.

  • Definitely best answer here. Not blah-blah-blah-philosophy.
    – john c. j.
    Commented Jun 20, 2018 at 6:54
  • // , This was my first thought, and although the philosophical answers appealed to me, the primary reason I use CLIs is because they are much more easy to reason about, standardize, and communicate to others over text. We may not all know how to draw, but we all know how to type. Commented Nov 6, 2018 at 21:59

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.

  • trunk? I think you mean master.
    – jpmc26
    Commented Feb 9, 2016 at 0:20
  • @jpmc26, I wrote this when I was new to git coming from SVN, pardon the terminology.
    – zzzzBov
    Commented Feb 9, 2016 at 2:13

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.

  • +1; and the easier / more accessible it is to use, the more likely I am to use it when at appropriate times (tap tap tap git commit tap tap tap) instead of (tap tap launch GUI git commit 'end of week commit')
    – Abe
    Commented Nov 3, 2012 at 6:29

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).

  • 3
    Actually, the concepts behind git are so simple that people cannot figure them out -- they are looking for something harder.
    – gahooa
    Commented Nov 3, 2012 at 1:07
  • I find that a good GUI helps explain the git concept.
    – pkamb
    Commented Dec 18, 2019 at 9:08

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 sentence answers rarely provide a lot of value. Can you please expand upon your answer?
    – Walter
    Commented Nov 2, 2012 at 14:29
  • // , He's the @grumpasaurus. What did you expect, a sonnet? Commented Nov 6, 2018 at 22:01

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.

  • Last point is quite key for me. Build scripts, tools and servers rarely have one using a gui for having the gui access version control. One must instead use the command line.
    – user40980
    Commented Nov 2, 2012 at 17:33

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:\Users\raviepic3\Desktop\Workbench 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:\Users\raviepic3\Desktop\ inside which we have content.docx . And now I want to create a new bare repository from this using GUI. I'll copy C:\Users\raviepic3\Desktop\Workbench.git and paste it as C:\generic_share\Bare_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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.