loading...

re: Do your commits pass this simple test? VIEW POST

TOP OF THREAD FULL DISCUSSION
re: Do you have a recommendation for how frequently one should make changes? For instance, I am working on a new feature today, and I plan on committin...
 

Commit frequency depends on the task and your workflow. We use feature branches with git.

When I'm adding a feature to an existing code base or fixing a defect, I usually do a bunch of refactoring commits. I try to keep similar changes together. So I'll get commit messages like:

  • run codestyle tool
  • refactor variable names (using refactor tool)
  • update documentation
  • add more unit tests

And then I'll write commits for the new code:

  • add new class x that does y with unit tests
  • add new class a that does b with unit tests
  • etc.

If it gets too big I break it into multiple pull requests. 8-10 commits per pull request is about as high as I'll go.

My main goal is to make my code changes reviewable. Having the refactoring changes separate from manual changes makes code much easier to review.

I also like the idea of using commits like a ratchet. So I'll commit when I'm about to move from a change that I'm sure about to one that I'm tentative about. Then I can revert quickly if I feel I've gone down the wrong path without losing the changes I was sure about.

Code of Conduct Report abuse