• CaptainBlagbird@lemmy.world
    link
    fedilink
    arrow-up
    8
    ·
    edit-2
    2 days ago

    At work we always put an issue number (together with a short summary text) in the commit message. The the verbose explenation is done in the issue, where formatting, search and filtering is easier. However this creates a dependency to that issue system.

    • Kissaki@programming.dev
      link
      fedilink
      English
      arrow-up
      2
      ·
      1 day ago

      I would hate to have to open Jira tickets to be able to understand code or code changes in Git history.

      I guess it depends on the quality of the summary. And how usable your issue system is.

      I’m sure I would continue to feel uncomfortable though, about the code and history itself not being self-describing. Issue systems change, become unreachable, etc.

    • Eager Eagle@lemmy.world
      link
      fedilink
      English
      arrow-up
      5
      ·
      2 days ago

      yeah, trying to convince our product owner to read commit messages wouldn’t go smoothly in my team. Some of them love their tickets…

      the dependency to the issue system is unfortunate though, I do miss a “decentralized issue system” doing what git does for version control that would just seamlessly integrate with git and have a nice web GUI for less technical folks.