31
Why don't people use git properly? | deadSimpleTech
deadsimpletech.comI think the worst failure mode I've ever seen is one team that maintained a "git repository" for a collection of analysis scripts that was simply a directory on a shared drive. It was technically speaking initiated as a git repository, but practically speaking it wasn't used as one: rather, the directory contained zipped copies of the code timestamped with when they were modified. There were very few commits to be seen, and I honestly hesitated to try and branch from them in any meaningful way. Of course there was no command line interface or anything to be had, and the git GUI software they had available was muddled enough that it confused me. In this situation, yes, *technically* they were using git, but in any real sense this clearly wasn't the case.
Very good article for folks who’ve had to teach juniors/trainees Git before.
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)