1. 11

Using commit messages as an example of improving practice through gamification

  1.  

  2. 4

    From the comments:

    I find commit histories useful enough to advocate small commits, but actually I don’t think it’s useful all that often, although when it is useful, it can be very useful. Its biggest advantage is probably in resolving merge conflicts, but honestly team sizes are a much bigger factor on that front.

    I can think of a few other reasons for small commits:
    1) Ease of code review as mentioned in the article.
    2) Each commit should be a single bug fix or a single feature. You should check out the rubbish my work mates commit, 2000 lines of “this is every change I have made locally since the last release”. Good luck code reviewing and working out the rationale for every line of that.
    3) Easy rollback, you know you are only rolling back one feature/bug fix, you don’t have to pick out some lines or functions but not others from a commit.
    4) Splitting up commits into parts: fix code style, move code/refactor, add feature/bug fix. The amount of times I have seen coworkers fix code style or move a function while at the same time adding/removing lines from inside the function or worse if the real change is modifying one character, but the white space of every line changed or the function also moved from one file to another, grrr.