Timeline for How often should I/do you make commits?
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 9, 2011 at 13:45 | comment | added | Karl Bielefeldt | I prefer to check in intermediate stages no less frequently than weekly, but sometimes that just isn't possible if you have to temporarily break a lot of legacy code in order to add a feature. My "once a month" comment was meant as a worst case upper bound, not as a regular practice. | |
| May 9, 2011 at 13:45 | comment | added | Karl Bielefeldt | @E.Z. Hart, it's not a matter of "learning to use branching features." Most companies don't allow the rank and file to create branches on the central repository, at least none I've worked at, because of the clutter hundreds of developers would create on a single centralized resource. Such decisions are made by committee, can take a month just to convince the right people, and feature branches are generally reserved for very large efforts by multiple people. | |
| May 9, 2011 at 13:42 | comment | added | Tamás Szelei | This really sums up my thoughts. Commit when I want a "checkpoint" that I can get back to if I screw up. Merge only when the feature is complete and the overall software is not broken. | |
| May 9, 2011 at 7:31 | comment | added | E.Z. Hart | "... you generally don't commit until you're pretty sure you won't get a storm of angry emails for doing so." Or you learn to use the branching features of your VCS so you can commit as often as necessary without committing broken code to the integration branch. If your company understands version control at all, then "once a day" will probably get you a warning. "Once a month" will eventually get you fired. | |
| May 9, 2011 at 2:48 | history | answered | Karl Bielefeldt | CC BY-SA 3.0 |