It’s why standards like conventional commits helps a long way in the workplace
That’s a lot of words. I think the reasons are pretty simple:
- Some people just don’t care.
- The Git CLI is poorly designed e.g. the many different ways to delete something.
- Some Git concepts are very poorly named, e.g. the “index”, “ours/theirs”. This adds to the confusion.
- There are many Git GUIs but only a very small number of actually decent ones (if you’re wondering: GitX, SourceGit, Git Extensions, and the Git Graph VSCode extension).
- There are a lot of idiots out there telling people not to use Git GUIs, when they are clearly the best way to learn how to use Git. Its easy to get into a mess if you can’t see what you’re doing.
- Git isn’t actually as simple as us pros would like to think. The underlying model and even the implementation isn’t too complex (I’ve written a Git client form scratch; not too hard apart from the lack of specs/docs). But you can easily get into a state where you’re pulling from a remote and someone else has pushed to the same branch so you need to resolve that (oh btw don’t do what Git tells you to!), and maybe it involves submodules too, and you basically need to fully understand Git’s model and be pretty good at the awful CLI too to resolve it.
The GUI thing is basically a religion.
I’ve mentored plenty of juniors that could barely commit+push.
Whenever they ask me for help to do anything remotely complicated the conversation is always the same.
+ you have to click here, then click there
- but how do I do it in the CLI though?
+ Idk, I barely use the CLI. I believe it’s
some git command. But you can easily do it in the GUI, it’s 2 clicks- <does the command> that didn’t work <wastes 20 minutes trying to make it work>
+ Fine, I’ll search for the command.
<5 mins later>
+ Here is the command
- that worked!
Every. Fucking. Time.
Yeah also people get into a mess and don’t understand the state of the repo. Like they’re organising files without ever running
ls. If you ask these CLI fanatics for the solution they’ll say “you don’t need a GUI, just rungit log --tree --oneline --decorate --all”… which is just a poor man’s GUI.
+1 on the Git Graph extension. Love it as a daily driver.
Very good article for folks who’ve had to teach juniors/trainees Git before.
This is, to my mind, one of the greatest advantages of git (and, by-the-by, also automated testing): the added security that being able to restore to an earlier state whenever you need to allows you to take more risks and try more things when building software.
Yeah, I always tell them it’s like checkpoints or like a save in a game.
But this also ties into the needing-a-teacher aspect to properly learn Git: Due to the nature of what Git accomplishes, it has a lot of complex failure modes. And at the start, you need a teacher to get you through those.
The worst-case is if they start dreading merges, because they can’t past them and then they try to merge less often, which makes the conflicts so much harder to deal with.
Or if they can’t get past merge conflicts and stop seeing the point in small Git commits and in good commit messages. That also makes merge conflicts so much worse.That’s kind of my motivation to be good at Git. I need to be able to tell juniors, that if they’ve created a commit, then we can unfuck the repo no matter what they might do wrong.
Most projects do not need the complex merging capabilities of git. I’ve found that simply structuring the workflow around trunk based development with linear history works the best: short lived feature branches that get rebased/squashed/committed and the tip of main is always deployable. It avoids dealing with all of the bullshit that comes with long-lived branches and migrating changes between them. This also requires structuring the work itself if you have a larger team so that if you are all working on the same system, avoid crossing the streams (draw some boundaries) to keep dependencies between branches at a minimum. When it starts getting into stacked patches, that’s a good sign you have a kink in the review pipeline somewhere and this complexity can go away with some managering. Git is as complex as you want it to be, and pretty easy to keep it simple
And here we are, encouraged by our technical leadership to always have a single commit per branch that is constantly amended. I even think squashing the branch is not too good, but this is a step up from that
Squashing is good because otherwise you have commits that are unreviewed and broken in your main branch which confounds git bisect, which is largely the only time most people even look at commit history
Largely yes, but also having it squashed requires better commit messages and comments to show what was done for what reason. But yes, bisect is the only reason I’m fine with squashing
It seems for some reason you assume people have better discipline for commit messages made in the course of a branch that will be merged, but that’s absolutely not true as a general rule. Additionally, even if the squashed commit message is bad, it will at least correspond to a PR in the forge.
Yeah, some commit messages are very not good either
???
If you mean to ask what that means, it’s that for development you start a branch and either do everything in one commit, or do everything in several, but each time you
git commit --amendso that a history is overwritten and in the end it is only one commit stillI understand. Just… y tho
Because less merge conflicts (we also rebase on top of master each time we commit)
I don’t agree that Git has a “steep learning curve”. you can literally pick up the basics for what an average dev actually needs in like 5 minutes. made a change? commit it. didn’t work? ok diff it or whatever or just go back to the working version. everything good? cool push it. done. That’s pretty much what most people just use it for. Is this the proper way? no it’s not but honestly who cares? I highly doubt Linus even cares or thinks about how people use or don’t use Git. By his own admission Git is just an afterthought for him, just a simple tool he needed for Linux and then handed it off to another maintainer at the first possible opportunity.
So no I don’t believe we need extensive courses or even an alternative “easier to use” Git. It’s a tool that can be learned in 5min for the basics of which the basics is all the majority of devs actually need.
Well it all starts at the very own git developers, since they don’t know how git should function, then how to expect anyone else to understand.
E. g. I just turned it in to somewhat functional svn with bunch of git aliases and cope with that.To be fair, I think those devs have a good idea on how a content-addressable-filesystem-cum-blockchain should work. The primary use-case, Linux kernel development, has very particular needs such as being distributed, allowing complex merge strategies, and being aggressively transparent. That the rest of the world then adopted this particular (D)VCS was mostly an accident.
Back in the before times when git was first new, I was an avid supporter of svk (a perl hack that bolted on distributed qualities to svn). Very useful to have complete server state locally especially for merging. svk worked, but had a lot of foibles, being the hack that it was. When I finally pulled the trigger and migrated repos over to git, even those early versions, reduced the complexity of my setup dramatically. Haven’t looked back since. The porcelain of git has improved dramatically over the years (even if I still use
git checkout -b). But it is still very much an expert tool and most users don’t engage deeply with it. Which is exactly what the blog post recognizes and laments because the supposed experts aren’t.What irks me about it is that they can’t even agree on simple things like should it have one command e.g. checkout for multiple things, or should it be separated to multiple (switch, restore, checkout).
They can’t agree are they making a tool for idiots or developers so they go from one end (reset) to another(restore).
So users end up with an entangled mess of a overlapping yet not fully covering commands.
Then comes the so-called “expert” saying:git is the shape it is for very good reasons, and we wouldn’t, for example, try and dumb down a milling machine or a lathe because they’re hard to use
Yet they don’t ask themself why do new users think it has too steep learning curve, or an entry barrier.
So calling it “expert” tool is mockery by my standard. (If not obvious I agree with Mira Welner, git is critically overdue for good command clean-up before there can be talk about experts)Maybe if newcomers had clear image of how git is supposed to work with clean easily explainable set of commands, larger percentage would stay on the wagon, just saying.
e.g. checkout for multiple things, or should it be separated to multiple (switch, restore, checkout).
I felt they were pretty clear here. checkout is overloaded. switch and restore are the new, simpler ways. I switched (ha) myself and it was painless.
I also get the reluctance to deprecate or delete checkout because the whole world uses it
