That's because it's the lowest common denominator. Anyone with Git on their system can use the command line and follow along. If you choose to use a GUI for your explanation, then you're likely alienating at least a portion of your readerbase who can't use / don't want to install that interface.
I agree that a GUI can make some tasks a lot simpler but, personally, I've always found that teaching people to use any DVCS from the ground up (i.e. from the command line) ends up with a greater level of understanding. Once you've got that, you can move on to using a GUI to improve your workflow, but with the understanding of exactly what is being abstracted away.
Yes, but if you choose to use a CLI for your explanation, you are alienating an even larger portion of your readerbase who can't use/don't want to use the command line. I'm thinking in particular of Windows developers, who have to put up with a CLI experience that borders on the unusable (or at the very least requires a lot of work to get it set up), and a culture that views it as the domain of poseurs and prima donnas into the bargain.
In any case, I'm quite sceptical of the claim that you can teach Git more effectively through the command line alone. Here's why: the two most important concepts to understand before you can properly grok DVCS are (a) that your source history is a key integral part of your workflow and not just a sideshow, and (b) how revisions, changesets and merges relate to each other through the DAG. GUI tools do this very effectively by putting your source history, complete with a graphical view of your revisions, right at the front of your workflow. By contrast, the command line requires you to type git log --graph, effectively relegating it to a sideshow like in the bad old days of Subversion.
I can't help getting the impression that learning DVCS through the command line risks you ending up with an understanding of the subject that is fundamentally flawed. You see this in virtually every Git versus Mercurial debate that focuses on which one is better at branching and merging. Most of the arguments that I've seen leave me with the impression that the people who are making them haven't a clue what they're talking about.
But this isn't really a newbie's guide to using Git, as far as I can tell. There are probably other texts that are more suitable for that purpose. This text was pretty useful for me as a refresher-type thing to clarify the basic data types and inner workings of Git.
There are many, many people who have no problems with using the command line, and who in fact by default prefer it to GUI tools. The guide itself provides graphs and visual means of understanding, and explains how these representations relate to the CLI tools. Very helpful!
I don't really agree with your complaint, because it seems like you're just saying "I would prefer to read a different kind of article," which is fine, but it's not a criticism. The argument about "alienating an even larger portion of your reader base" seems spurious; the author can write to whatever target audience they want!
My problem isn't with this article specifically. In fact I'll probably find it quite useful myself: it's one of the clearest presentations of Git's internals that I've seen so far. I personally have no problem with the CLI tools either: I myself use PowerShell (with Posh-Git), Git Bash, vim, you name it, and for most things I actually prefer it.
But the fact of the matter is that the Git community is churning out articles such as this one left, right and centre, while ones at a more readily accessible level are being neglected, and therein lies the problem. While there are many, many people who do not have any problems with the command line tools, there are also many, many people who do -- especially in the Windows and .NET world. The fact that we have a glut of command-line focused low-level Git tutorials and a dearth of more readily accessible ones, combined with the common attitude in the Gitosphere of "if you're using GUI tools you're doing it wrong," paints a picture of Git to people such as these of an ecosystem that is elitist, arrogant and user-hostile.
It's nothing to do with the kind of article I'd like to read. It's everything to do with bad marketing.
It would have been really useful if the upgrade notification had included this level of detail to start with so people could make a much more informed decision about when/if to upgrade, rather than having to dive through bug reports, commits etc just to work out if our apps are vulnerable.
You could raise the same argument about all the time they spend releasing open-source software, or producing the really great presentation slide decks that they do.
Regardless of the fact that a well-designed application encourages people to use it more, the fact that GitHub provide their employees with the opportunity to produce such well-polished interfaces is an incredible marketing tool for potential new recruits.
At the end of the day, it all fosters an environment where developers want to be The Guy That Works at GitHub, and all the great talent they attract just bolsters their position even more.
Global Personals, based in Windsor, UK, are looking for smart developers to join our engineering team, as well as Rails devs: http://globaldev.co.uk/jobs/
