Visual Git Cheat Sheet
ndpsoftware.com
ndpsoftware.com
Is it because the complexity is really needed, or if papering over them and making it user friendly has failed? For example, you won't find a cheat sheet of SQL commands submitted and upvoted so many times on HN, even though SQL implementation and internals are very complicated. Reason being it's able to hide the implementation details and abstract it away.
At the very least the terminology in git is very confusing. Especially 'checkout' for people who came from a SVN/CVS background.
I think the above problems mainly come down to the fact that it should be a GUI but isn't. Which is why so many GUIs are built on top of it, but then they're shaky because they depend on a CLI which is itself trying to be GUI-like. I would honestly take a text-mode GUI over what we have, and I don't even use text-mode GUIs normally.
I always say, git is the worst VCS except for all the other ones.
Magit (https://magit.vc) solved both problems as far as I'm concerned. It shows the current git state in a clean, easy to explore way. It also makes it easy to change it as needed. It also hides most of the CLI oddities by building commands for you from a well designed menu system --- some weirdness will remain: bypassing hooks is "-n" for a commit and "-h" for a push for example. That's the price of staying close to the CLI. And the result commands can be seen and checked if one wants to. Magit makes the git options visible and discoverable in a compact way, and expressing what to do easier.
To me that made the difference from preferring sticking with subversion or using mercurial, to preferring git today. In particular, the index is a very powerful tool to break a lot of changes in a set of nice "atomic" commits once done. I really appreciate it now that I can easily visualize it and control what's there, and trivially sends specific line changes to it.
Sure, Magit is tied to Emacs. But it's possible to use Emacs just for Magit. I'd recommend anyone having problems with git UX to have a try. Some people may joke that now they have 2 problems, and that may be true ;), but for someone that can deal with the Emacs basics I'm positive Magit will be a plus to deal with git.
And we now have plenty of people who would just need a knife to cut fruit, and are instead cutting their fruit with a surgery-grade remote-controlled high-precision cutting robot, and spending lots of hours learning the fine detail on how to operate such a robot (trying to get by with only 4 or 5 buttons of the hundreds of buttons and knobs in the robot, but often failing and needing to look at the manual to undo their errors), because you need to upload your fruit "surgery-grade-remote-controlled-high-precision-cutting-robot-fruit-hub" if you want it to have visibility.
Hg is much more intuitive and I'd say 90% of git users would be happier in an alternative timeline where it had triumphed. Darn, even SVN was much more intuitive UI wise, even if of course it falls short on functionality these days.
It's the opposite of user-centric design, like a car with no body where you adjust the gasoline pump, the transmission, the amount of oil etc. yourself.
There's an underlying model, which is tricky but not rocket science - and all actions on that model can have a bunch of non-obvious state changes and side-effects.
It's just complicated enough that it's hard to keep track of the models+statefullness without some expertise, experience and thought.
The first time I saw an 'animation' of what was going on with various commands, it blew my mind how much I learned as I saw things happening.
The language we uses is often not very specific and leaves out important details.
We use it because there's a kind of simple brilliance to the underlying model, it's very fast, very robust, and works well for open source.
That said, I wish there was a git optimized for teams and with better abstraction.
I've thought about writing a subversion compatibility scripts overlay for git, just to make my live easier.
Unless you are using git as a centralised SCM, the concept of a linear revision doesn't quite match up.
Of course many workflows between different branch and people do eventually end up with there being a "master master" (or a main main to use more up-to-date terminology), and workflows for single dev projects naturally do, perhaps in those cases you could wrap relevant git commands in something that increments a build number stored in a file before relevent actions.
It perhaps do away with a simple increasing revision number and use the date of merge on that branch, which would at least always be increasing.
Though it isn't git's failing when people use a distributed SCM in a centralised manner and expect it to be optimised as such!
They're using git with Gitea or Github, or Gitlab, there is a defacto centralized master.
I've been through 3 source control systems now, and Git is by far the easiest. I only branch, clone/init/add/commit/push/pull and merge. (And now most through the gui in vscode) There are some minor fixes I've had to look up, but it's rare.
Almost all the complaints I hear about are from very obscure commands and situations I've never seen.
Is using Git in a simple way the answer to everyone's problems with it?
When my level of understanding of git was "add/commit/push/pull", if ever I made a mistake, I'd then have to try a more sophisticated command which would then risk making another mistake.
The GitHub repo: https://github.com/ndp/git-cheatsheet
All this information is already natively available in the help menus, and new people should probably generally stick to things like egit if they're completely lost and need a beginning grasp imo.
Click a box and you get all that's coming, and all that's going, to that box.
Hover over a command and the display area at the bottom of the screen explains the command.
If you're looking at this on mobile, and puzzling why this might be a great thing, this predates your device's tech by a very long time.
like workspace vs. local repo. that IS NOT explained, but all kinds of stuff about stashes is present.
people that know git very well have no clue how to teach git to others. none.
I feel like the two main reasons people don’t understand git is that they start by using a GUI instead of starting with the command line, and that they don’t understand fetch.
My point was really that understanding git doesn’t need to be overly complicated in the end, if you just focus on key concepts, such as the notion of git fetch updating the remote branches within the local repository (and hence status being a reflection of that)
If the author is reading, just an observation; because the local repository column is pretty solidly coloured, I kept confusing it with the selected column.
Also there should be another line with 'checkout -- <file>'.
Edited: the columns are clickable.