Some best practices for using Git | Hacker News Reader

Some best practices for using Git

deepsource.io

25 pointsdolftax11 comments

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?

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.

Lots of different opinions here. I prefer seeing how the sausage was made, just as much as I know that unsettles some folks. Git has a DAG for multiple reasons, but a DAG also gives options for not sweeping everything under the rug in rebase/squashes. I think graph traversal options like --first-parent are more interesting ways to get "clean" commit history logs in "master" than rebase/squash.

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.

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?

It is not ideal, but ... Get a GUI and pick out lines and files and multi-commit your changes.

`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.

Didn't know about that. Thank you.

YMMV, but when I'm working on a feature branch that can take some time, I try to break it into pieces to merge into master often. One way to think about this is breaking away from the compulsion to commit the entire thing together in a branch. So I have `feat-x-part-1`, `feat-x-part-2` and so on.

It's important to resist the urge to do push things only on perfection. It works for me.

I try to emphasize that commits should not be thought of as "save points," which seems to be a seductive way to think of them, but as "undo points."

That is a good way to think. Thanks.

Reply on news.ycombinator.com