• jjjalljs@ttrpg.network
    0·
    10 months ago

    My commits when merged into main generally read like

    [Ticket-123] Summary of what was done. Eg: Return user foo property in bar endpoint

    • update bar view to return new foo key
    • update foobrinator to determine foo property
    • update tests

    It takes an extra minute or two but it’s more informative for the team / future me.

    • onlinepersona@programming.devEnglish
      01·
      10 months ago

      Mine look similar except the body is mostly “the X was doing Y, but it should’ve been doing Z” or “the docs say bla, $link”. I try to separate the individual “update A to do B” in separate commits, but sometimes it just isn’t possible.

      CC BY-NC-SA 4.0

      • jjjalljs@ttrpg.network
        0·
        10 months ago

        We squash everything (and rebase rather than merge) so I don’t worry much about the individual commits. I like that main is pretty concise and doesn’t have a ton of work-in-progess stuff in the log.

        • onlinepersona@programming.devEnglish
          01·
          10 months ago

          We are mortal enemies you and I 😄 I’d much rather have a descriptive commit history than huge commits which make git blame meaningless. Function over beauty for me.

          CC BY-NC-SA 4.0

          • jjjalljs@ttrpg.network
            0·
            10 months ago

            A nemesis! I’m pretty lucky I guess that no one at my workplace has strong git opinions that differ

            Do you have multiple people’s commits being squashed together? Or how is blame being made useless for you? I’m at a rather small company where generally it’s just one person working on a thing at a time. The blame will point to their squashed commit that, if they wrote a good message like the top of this thread, will give you a lot of context.

            • onlinepersona@programming.devEnglish
              01·
              10 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

  • Justas🇱🇹@sh.itjust.works
    0·
    10 months ago

    I remember making a bunch of fixes and calling them after Star Wars movies with the thing I’m fixing or what was broken as the noun.