Jammycakes has a good point about certain features like interactive hunk selection being much easier to do using a GUI.
But, git's natural habitat is the CLI, git was designed with and for the command line. There are no GUIs (yet) for git that expose git's full power, and I wish there were.
And there are no GUIs (yet) that actually make git easier to understand (as opposed to making some known git workflows less labor intensive) -- I also hope for this in the future, but it will require a more fundamental redesign of git's interface and terminology.
Adding menu options with the names of things git does makes git slightly more discoverable, but not much easier to understand. For better or worse, I think understanding git from the command line point of view is (currently) critical to a deep understanding of git, even if you're using a git GUI.
"And there are no GUIs (yet) that actually make git easier to understand (as opposed to making some known git workflows less labor intensive) -- I also hope for this in the future, but it will require a more fundamental redesign of git's interface and terminology."
I heavily disagree with this.
When I started heavy use of git branches, being able to actually visualize what a branch is (e.g. just a pointed, as the article points out), being able to actually see the various branches merging into each other, it all just made my life easier.
When I used to explain git to our new employees, it was in the CLI, but I quickly moved to explaining it GUI-first because I could teach all the concepts much more quickly and they clearly understood better that way.
Its a fair point that visualizing branches makes a big difference to people learning git. One reason that all git intro articles have these A->B->C diagrams.
FYI, the git CLI can give you branch visuals, e.g., 'git log --graph'. I was honestly thinking beyond basic branching when I wrote the above, but its worth remembering that the basics matter, and I also wouldn't even disagree with someone who claimed a GUI branch graph is easier to look at than a CLI branch graph, even though there may be no informational difference.
Still, I think the larger points I was trying to make stand:
- There is no git GUI that can replace the git CLI. There are many GUIs that give you pieces of git's workflow, but none complete enough to be a true one-stop-git-shop -- especially when it comes to more advanced workflows & repo administration.
- Git was not designed for a GUI, it was designed for a command line, and it shows in many ways. The CLI is the only place you can use all of git's power and understand all of git's features. It's also, as wildlyinaccurate was trying to explain, the lowest common denominator interface, hence the easiest to start basic explanations with. All people who have git have a CLI interface. Written with any GUI in mind, and a git tutorial immediately loses the majority of its potential audience.
But I would point out that the "advanced" functionality of git that you're talking about is something 99.9% of people will never use. Hell, even branches is something that most people don't use.
But, git's natural habitat is the CLI, git was designed with and for the command line. There are no GUIs (yet) for git that expose git's full power, and I wish there were.
And there are no GUIs (yet) that actually make git easier to understand (as opposed to making some known git workflows less labor intensive) -- I also hope for this in the future, but it will require a more fundamental redesign of git's interface and terminology.
Adding menu options with the names of things git does makes git slightly more discoverable, but not much easier to understand. For better or worse, I think understanding git from the command line point of view is (currently) critical to a deep understanding of git, even if you're using a git GUI.