DEV Community

Discussion on: Plan Your Commits

Collapse
 
esantoro profile image
Emanuele Santoro

This seems utterly unpractical and error-prone to me.

A better approach would be, imho, to just commit as often as you can.

Ideally, after every micro-iteration (at each stage when something is working).

Why is this approach better?

  1. No worries: you committed.

  2. Better time-travel possibilities.

  3. At the end of the day you can squash all of your micro-commits in one big juicy commit that includes every changes made to implement a function.

It's nothing hard: it's just git rebase.

Collapse
 
joeaudette profile image
Joe Audette

Totally agree, merging is to be planned, committing is to be done frequently. Anyone who has ever lost work from hardware failure knows this. At any point when you have work you would not want to lose, commit.

Collapse
 
mbfgwip profile image
Dave Brosius

Exactly, early and often, to a user/feature branch, then rebase/squash them as needed before merging to a 'real' branch.