On Mon, 2013-07-22 at 18:58 -0300, VinÃcius dos Santos Oliveira wrote:
I like to make commits that don't break. Following this rule, I also like to make small commits that change small parts of the code and are easy to track.
The policy I follow is:
Is the branch going to be released -> trunk==yes, dev-branch==no Breaks should be avoided in released branches but encouraged in dev-branches. It sounds odd to encourage broken code, but the more adventurous and the less shy, the less likely developers spin their wheels while their subconscious calculates risk vs reward and get stuck second-guessing the ability to hit a home run with every contact with the code.
Broken code can be fixed, uncommitted or reversed, non-existent code can't even be seen.
Small changes is a good plan, nice and smooth. Easier to see the progression and once merged all those get collapsed into a nice subtree.
Martin,