
Some best practices for using Git - dolftax
https://deepsource.io/blog/git-best-practices/
======
sys_64738
Every git commit should have a ticket ID.

Squash all commits! No development commits in master branch.

~~~
wodenokoto
Once squashed, how do you go back to the dev commits?

~~~
zdwolfe
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.

~~~
WorldMaker
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.

------
Sourya
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?

~~~
WorldMaker
`git add --interactive` can be a great tool to learn in this case:
[https://git-scm.com/book/en/v2/Git-Tools-Interactive-Staging](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.

~~~
Sourya
Didn't know about that. Thank you.

