
When to make a Git Commit - bhalp1
https://dev.to/gonedark/when-to-make-a-git-commit
======
jasode
The author is giving out bad advice that's not relevant to Git's mental model.
He's using the CVS/SVN old mental model that treated commits as A Really Big
Deal instead of embracing Git's new way where commits are merely a savepoint.

Instead, commit to your _local private_ repo _whenever_ you want. Whatever
spurious commit you want to make, just do it without thinking. (E.g. _" WIP
stopping temporarily to go get a soda"_). Then use rebase if you want to clean
things up.

EDIT ADD: reading the essay again, the author may be restricting his advice to
commits on _public master_. If so, the blog's title should make that
distinction prominent because that drastically changes what the _" when"_ in
_" when to commit"_ means.

~~~
WorldMaker
Or don't rebase and teach people to use tools like `--first-parent` and learn
to love the DAG. Git log doesn't have to be a perfectionist's straight line.

------
bostand
There is really nothing wrong with committing often. For me a unit of work can
be fixing a typo. Of course if you share code with others or user CI/CD you
might want to commit only working code.

You can always rebase before pushing upstream.

------
rerx
I find Magit mode in Emacs to be very useful to create coherent and concise
commits. It has a fabulous interface for picking out the chunks of an edited
file that should be staged.

------
beters
It makes more sense to err on the side of committing too often. When you're
ready to submit, use 'git rebase -i' to squash away any silly commits. Done.
No blog post needed for this topic.

------
raarts
Even on public repo it makes sense to keep commits small enough in case you
need to do a bisect later on.

