Comment by SebastianKra 2 days ago
We should start recommending UIs as the default way to learn Git. It would solve a third of these problems and another third wouldn't even come up.
If you later decide that the CLI is faster, go ahead. But first, people need to see visually how they can interact with the tree.
I like fork.dev, but most clients are pretty similar at this point.
I've started recommending jj as a (git compatible) alternative to git, and one of the things I like about it is that the default action if you run `jj` with no arguments shows the relevant parts of the commit tree and where you are in it. This is a great reorientation tool, because you can see at a glance which commit you're working on right now, the branches and history associated with it, any other active branches in your repository, and for each you can see whether each commit had messages, changes associated with it, etc.
It's really powerful because it gives you precisely that visual layout that shows you what's going on in the repository, and what you're doing right now.
GUI git clients are amazing in the hands of expert users, but terrible for any newcomer that has to actually use Git (and it's not like a designer checking out the source once or twice a month).
The gripe I have is that unless you expose people to CLIs early on, they will just not learn how to use a CLI at all. Whenever something inevitably breaks badly due to GUIs abstracting away how git really works in favour of a nicer UX, they'll end up asking someone that know Git how to fix their mess. And then, it's too late - they already know how to be productive-ish with git and how to deliver something. They can't justify investing time into learning the CLI (especially if they're not that great with Powershell or UNIX shells) so they constantly keep leaning on a colleague instead of learning.
This is not an hypothetical scenario - this really happened regularly at a place I worked at. Innumerable internal training lessons on Git went wasted due to people forgetting everything immediately by using Fork instead of the shell, and then pestering a handful of senior devs. Once IT banned Fork people were forced to use the terminal more often, so they had to learn how to use git for good and actually retained that knowledge via muscle memory.
The adage I've learnt over the course of the years is that the majority of people will go to any length to avoid learning new stuff. It's mentally less tiring to either waste their time doing stuff in an unproductive way than learning new things. IMHO it's better to force people to learn stuff the "right way" early on than let them pick up bad habits and then having to correct them later.
I advocate this with every newbie to git - find a UI that works for you and use it over the cli. Barely anyone listens though, and then they struggle with the cli and make a mess of their branches and fall out of date with main and are scared of rebasing and have many other issues that are solvable with a drag and drop or similar in a UI. I figure it's a sort of masochism.
I have not used such a tool in a long time, and never with git: but my past experience with GUI frontends for version control was that they work fine when everything is working fine, but once you have a mess to clean up, nobody can help you.
It has generally worked better for me to use the same interface everyone else is using, even when that interface is awful, because that eases communication with the rest of the team. It also lets me take advantage of online troubleshooting resources, which all assume you are doing things the normal way.
> But first, people need to see visually how they can interact with the tree.
Interactive tutorial with tree visualization that has helped co-workers: https://learngitbranching.js.org/
The cli is faster if you know by heart but a real disadvantage is that it is hard to "see" what you did or what happened in the past. Good look finding where/whether an old branch got merged and find out if it is part of a release, using cli.
Is this really true? When I want to reorder commits, I just drag & drop in a GUI and I’m done. Or if I want to switch branch or manage a complex mix of rebases or cherry picks, it’s just 2 or 3 clicks. In CLI, by the time I’ve typed out the commit hash or locator, it’s already taken longer. And I type 130 words per minute.
> by the time I’ve typed out the commit hash
i don’t think i’ve typed out a full hash in … years? if i have i’ve used the short 8 character hash.
git rev-parse might be something useful to have a look at, especially when combined with aliases.
lazygit ! Just needed to throw out a mention because it’s an amazing tui for visual orientation, is super fast, and can be used with a mouse and keyboard (or just keyboard) from the terminal. I saw it mentioned on a thread here last year and have preferred it as a fast “oh crap I think I made a mess lets back up” tool over the more complex gui apps I’ve tried (almost all of them).
I agree, I have used git for more than 10 years and it's the only tool that I refuse to learn. The command-line interface is cryptic and infuriating. I'd rather write assembly language again than learn what is essentially a CLI to the internals of git. It's not high-level, it's not intuitive, and it can be destructive if you don't use the right option. I stick to GUIs and simple actions, and I never had any problems compared to all the horror stories of my CLI-loving coworkers.
As a magit user I agree, apart from the fact most GUIs I've seen are horrendously broken and can lead to an even worse mess. For example, I was really confused about how a colleague messing up and got them to show me. Turns out in VS Code if you set the upstream branch correctly (ie. to master), it tries to get you to "sync" the branch. So it assumes the upstream branch is the branch you push to, which makes no sense at all.
What the average amount of time until something goes wrong that can't be fixed in the UI?
In more than one team I've been on over the years, I was the only person with a deep understanding of Git. What I've found as a result of being the "oh shit git" guy is that
1) all UIs are completely missing at least some of Git CLI's functionality (shoutout to git's most neglected feature, git notes)
2) all UIs have at least a couple git features so tucked away that you'll only find them if you know to look for them (git checkout -- path > temp_file is a common culprit here, but I've seen UIs that hide git ammend)
3) the average time for a UI-exclusive user to need my help for one of those two reasons was about a month.
For me, once a year and I have to use the reflog. But using a GUI is so much faster and safer that I won't change. Mercurial and Jujutsu have good command-lines, why can't git do the same?
disagree, with a caveat.
to summarise: use the desktop apps now, but thou shalt need to learn the CLI.
—
when i’ve taught absolute development beginners how to use git and how to do PRs i show them both the CLI and GitHub desktop. not every single thing. but i at least show them add/commit/push and creating/checking out branches in the CLI.
why?
1) this CLI thing is what power users / experienced folks use. this is your long term goal.
2) oh look, the terminal is typing things out instead of clicking on buttons which have slightly different names (target audience has never seen a terminal)
3a) some things cannot be unfucked in a desktop app. i don’t have to explain what the CLI is to show them how to unfuck it. i might have to remind them. but it’s not totally alien to them. they’re only seeing the fix for the first time, not the fix and the CLI.
3b) they might feel more comfortable trying to use the CLI when they’ve already been shown it before. ideally in tandem with 3a — “hey i need to do this thing to unfuck it, could you sit with me while i go through to avoid fucking it even more”
4) maybe they go “screw it, i want the pain because i really want to be a magician at this”. it’s nice for them to have the option of the easier, simpler path when they’re having a bad day with it.
ill always suggest that absolute beginners use the desktop apps because it does reduce early fuck ups. and part of that involves showing them the desktop apps.
but i feel they need to be made aware the desktop apps are not the be end and end all. they can try the CLI a few times if they want. at some point, they will have to use it.
they also need to learn to fuck it up. making mistakes is how human beings really learn.
both making mistakes and demo-ing the CLI early, often and safely; rather than later and rarely; gets people to “magician” level faster in my experience.
essentially, you have more to learn buddy. keep working on it if you want to be one of the magicians in the team. if you don’t, that’s fine. but at some point you’ll need to deal with this CLI thing.
—
> people need to see visually how they can interact with the tree.
i’ve got a whole diagram thing i draw live showing them how everything is based on commits or a collection of commits, moving the commits around in front of them.
seems to be a better way to cover remotes, branches and eventually PRs than leaving them to work it out with some history visualisation which is usually a bit hard to read.
Agreed that UIs generally provide a better UX for Git.
I use Magit and doing things like "abort cherry-pick" is discoverable in the interface itself and uses the exact same shortcut as the other "abort X" operations. If I had to use the Git CLI, I'd have no idea where to start.
Similarly, I've made mistakes in interactive rebases where I deleted a commit that shouldn't have been deleted. If I recall correctly, the start of every rebase creates a snapshot that is accessible from the reflog, so this is a safe way to revert changes from a rebase gone wrong. Magit's UI for the reflog is exactly the same as the UI for the log, so I was not lost when I saw it for the first time. With the Git CLI, I'd likely have no clue what's going on.