• onlinepersona@programming.dev
    link
    fedilink
    English
    arrow-up
    0
    arrow-down
    1
    ·
    6 months ago

    Imagine finding a bug in angularjs, doing a git blame and finding this commit

    feat(module): new module loader

    211 changed files with 1,051 additions and 1,242 deletions.

    AngularJS isn’t even the worst offender. I’ve seen backports of multiple fixes getting squashed into one commit for “a clean history” with all the useful commit messages ending up in one commit.

    Many user stories I’ve seen implemented in a sprint take multiple days to write. Sometimes they have 5+ commits with a multitude of files changed and (if done right) each commit has an explanation why something was done or at least what was done. Having a granular view of changes also allows finding related changes quickly with less code to read.
    If someone changes the implementation of a function call in one commit and it introduces a bug, it’s nice to have only that change instead of the entire class with it and changes in other files too. Additional changes mean now you have to read through more code to be sure that the function implementation change was not done due to a modification of the class or whatever else was changed which might be the actual source of the problem.

    IMO squashing commits has its uses. It’s a tool in a toolbox, but it’s not the only tool.

    CC BY-NC-SA 4.0