I'm a small business programmer. I love solving tough problems with Python and PHP. If you like what you're seeing, you should probably follow me here on dev.to and then checkout my blog.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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:
And then I'll write commits for the new code:
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.