this post was submitted on 04 Jul 2026
27 points (88.6% liked)
Git
4712 readers
15 users here now
Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
Resources
Rules
- Follow programming.dev rules
- Be excellent to each other, no hostility towards users for any reason
- No spam of tools/companies/advertisements. It’s OK to post your own stuff part of the time, but the primary use of the community should not be self-promotion.
Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License.
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.
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)
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