11–13 of 13 posts
Every git commit should have a ticket ID. Squash all commits! No development commits in master branch.
Once squashed, how do you go back to the dev commits?
Great pointers. However, I have found that even though quite a few people know this, it takes special effort to enforce it. For example, the single-purpose commits. My commits often tend to get a bit large, and include more than one "unit" of work, even though I know the best practices. Any pointers on how to avoid that?
`git add --interactive` can be a great tool to learn in this case: https://git-scm.com/book/en/v2/Git-Tools-Interactive-Staging In particular, the ability to only stage specific "hunks" at a time (interactive "patch" in the nomenclature of git) can make it possible to "untangle" multiple changes in your working directory into separate commits.
Earlier quoted context omitted.
Once squashed, how do you go back to the dev commits?
My dev commits are usually of the form "Add test for Foo.bar", and every master commit has a dozen or so of these dev commits squashed together. Dev commits are not usually immediately useful to anyone other than the author.
I've seen (and had to help junior devs fix) far more broken branches due to rebase/squash commits than merge commits in git, that I've almost considered finding ways to entirely disable rebase/squash on projects I work on. They are useful tools that I still sometimes use locally during development myself, but I'd much rather see someone's messy laundry in their commit history than a clean history with an accidental merge bomb lurking under the surface where it isn't even obvious a rebase/squash went bad until you've got the regression report and angry users.