NGL, I have made (almost) all of these mistakes at some point. I am sure most others would have as well. Pretty nice compendium
Oh Shit, Git
11–20 of 237 posts
Re: Oh Shit, Git
#12The best part is the header alert - if you don’t like the profanity, check out dangitgit.com!
Re: Oh Shit, Git
#13Just delete the directory and clone it again.
Re: Oh Shit, Git
#14> This usually happens to me if I commit, then run tests/linters... and FML, I didn't put a space after an equals sign This is why it's good to put the linting in a git hook on commit or stage, so you literally can't commit without being formatted correctedly.
I generally don't like putting linters on commit hooks. Commits are easy to change and I think people would be better off making more of them. If your lint ends up taking a long time it will discourage frequent commits.
Also, unless you jump through a lot of hoops, linters generally run against what's on-disk instead of what's actually going into the commit. So checks that run at commit time discourage partial adds.
Re: Oh Shit, Git
#15My mental model of a git repo is basically a bramble bush with labels on it.
The bramble stems and branches are the commit history (which may join and well as split, unlike a bramble). The labels are stuck to particular bits of the bramble. Some labels are even stuck to other labels!
You can move the labels around, and you can glue extra bits of bramble to the tips of what you have. You can even hack about with the bramble, but this is not recommended. Label moving often happens automatically, e.g. when 'growing' a bramble tip.
It gets interesting when you compare two brambles (e.g. remote and local repos). You might determine that one bramble is identical to another, just with the labels moved. Or one bramble is the same as the other but with extra stems added. Or both brambles had a common ancestor bramble, but now they both have extra stems. Or perhaps they are completely irreconcilable.
Better visualisation tooling would help.
Re: Oh Shit, Git
#16For someone to get out of a mess they would have to know that they caused a mess in the first place! I'm starting to think trying to get people to use rebase and squash is a losing battle when they frequently just merge without pulling.
Re: Oh Shit, Git
#17Git is a reminder why even the best minds in software development sometimes really should talk to UX/UI people.
Git was built with a very specific use case and aimed at an extraordinarily technical subset of users.
It dominated the world despite the UX flaws, which suggests they really aren't that bad.
Re: Oh Shit, Git
#18Just delete the directory and clone it again.
Or you can spend some time once to understand how git works, and never run into a similar situation again. git is built on a beautiful and very simple model, and it's easy to unbreak the repository 99% of time if you understand it (and I'm saying this as a very mediocre programmer).
Re: Oh Shit, Git
#19For someone to get out of a mess they would have to know that they caused a mess in the first place! I'm starting to think trying to get people to use rebase and squash is a losing battle when they frequently just merge without pulling.
I got my team on side to use rebase/squash instead of blind merge commits after I showed them how much easier git bisect is to use when you have a linear commit history in your main branch. Now nobody wants to be 'that person' who breaks the bisect feature in case we urgently need it.
Re: Oh Shit, Git
#20> This usually happens to me if I commit, then run tests/linters... and FML, I didn't put a space after an equals sign This is why it's good to put the linting in a git hook on commit or stage, so you literally can't commit without being formatted correctedly.
I dislike that approach as it slows down committing. Preferably linter should be integrated in the editor and there should be one in the CI pipeline, but the steps between writing code and pushing it into CI should be as quick and smooth as possible.