Menu
What is the general rule? When do you commit?
567
The general rule (for both scenarios) would be: Commit as often as possible. If you think "it's not ready yet" (because it'll break the build or simply isn't done yet) then create a branch and commit to that branch but make sure you do commit.
Establish a branching and tagging practice. Tag major bug fixes at the beginning and end of the work. Maintain tags (and possibly branches) for production/qa releases.
Depends on your source code system and what else you have in place. If you're using Git, then commit whenever you finish a step. I use SVN and I like to commit when I finish a whole feature, so, every one to five hours. If I were using CVS I'd do the same.
Commit early and often. It minimizes conflict resolution steps when working in a team. But don't commit anything that breaks your build. Ideally, continuous integration notifies the team when the build breaks.
149
I try to commit whenever I complete a 'piece' of work - as long as the code compiles, of course.
30
This is covered (and covered well) in an older post on best practices.
SVN best-practices - working in a team
I'm recommending checking out this post because it covers a lot of good ideas, not just how often to commit.
36
If working on trunk, I commit whenever I hit a milestone that won't impact my teammates. When working on a private branch, I commit whenever I hit a milestone I don't want to lose (I don't care if it even builds). For personal projects, I use mercurial and commit constantly. It all depends on what works for you and your team.
31
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
