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 committing after I'm done in about three hours. Does that make sense?
I start with everytime you hit save. Can you describe your change in one sentence? Commit it. Then after you get into the rigor of committing that frequently, then you can begin to scale back. It's more art than science.
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.
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 committing after I'm done in about three hours. Does that make sense?
I start with everytime you hit save. Can you describe your change in one sentence? Commit it. Then after you get into the rigor of committing that frequently, then you can begin to scale back. It's more art than science.
Every time I save? Good lord! I save at least once every 2 minutes.
Lol, but you get my point. It's extreme, but you have to think about the changes you made. Adding classes and methods can constitute a commit.
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.