cross-posted from: https://lemmy.sdf.org/post/1352760

Was digging through a project at work today where some guy in 2014 made 100+ commits in a single day and the only one that had a comment said “upgrading to v4.0”.

    • Jim@programming.dev
      link
      fedilink
      English
      arrow-up
      5
      ·
      1 year ago

      Yep, this is the convention. Unfortunately, I’ve never been able to enforce it. Encouraging good git commit messages is probably the bottom of the things I can coach. I’d be happy if commits were properly squashed/rebased and that we all followed the same PR merge strategy.

  • canpolat@programming.devOPM
    link
    fedilink
    English
    arrow-up
    13
    ·
    1 year ago

    The way I commit on my private branch is different than how I merge those commits to the main branch. When working on the private branch, things can get messy and if they do, I just try to keep certain things separate from each other (refactorings and bug fixes should not go into the same commit). Once the work is done, I do a interactive rebase to tidy things up and then merge them afterwards. Sometimes the changes are not that much and it becomes a squash commit. I would definitely refrain from creating 100 (insignificant and possibly back-and-forth) commits on the main branch.

      • canpolat@programming.devOPM
        link
        fedilink
        English
        arrow-up
        4
        ·
        1 year ago

        Maybe my explanation was complicated, but what I describe is not time consuming. It takes at most a few minutes to do all of the things I mentioned. The difficult part is discipline of keeping refactoring separate. Once that’s done, the rest is trivial. And not all work include refactoring. That’s even easier then.

        • nittiyh@lemmy.world
          link
          fedilink
          English
          arrow-up
          2
          ·
          1 year ago

          Discipline is definitely tough. I have tried looking at rebasing tutorials and it always looked pretty tedious to do, hence my comment about time constraints. I should really give it another try though.

          • canpolat@programming.devOPM
            link
            fedilink
            English
            arrow-up
            1
            ·
            1 year ago

            Interactive rebase is used to organize (squash, drop, reorder) commits and with some experience is totally painless. Would definitely recommend watching a few videos about it.

      • Teddly@programming.dev
        link
        fedilink
        English
        arrow-up
        2
        ·
        1 year ago

        I used to find rebasing annoying until I started using lazygit. It makes it really easy, now before opening a PR I just interactive rebase on top of latest main and I can easily clean up my commits before opening the PR.

  • unknowing8343@discuss.tchncs.de
    link
    fedilink
    English
    arrow-up
    6
    ·
    1 year ago

    As someone said in the original post: Conventional Commits. No more discussion is needed. Just do it like the standard and get back faster to the real work.

  • sucks_syntax@programming.dev
    link
    fedilink
    English
    arrow-up
    3
    ·
    1 year ago

    We have a monorepo with multiple websites and applications, we also use azure DevOps. Our commit messages are formatted like this: {website/application} - {feature} - {brief description} - {#work item} so e.g. “Auth - MFA - auto focus login field #162589”

    The most beneficial part is the work item number, being able to link the code changes directly to the business logic is huge.

    Also beneficial for bug fixes, push the commit with the bug id and the code changes are linked on the ticket automatically.

    • Tuna Casserole@programming.dev
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      Oh I like the work item number idea. We’ve been putting in a line to explain why the change is being made. Being able to link directly to a card or something is noice.

  • Kissaki@feddit.de
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    1 year ago

    Driven through me as Lead Developer, we’ve adopted a Conventional Commits style using convco for conformance check and changelog/release note generating (customized template).

    feat(auth): Introduce configurable permissions (ticketref) (!MR)
    

    We’ve extended allowed/used types of fix and feat to include docs, test, refac, and misc. We explicitly decided against types like @CodeSupreme linked like style, perf, build, ci, chore, revert. Slim number of types has value. build, ci are scoped to misc(proj) or misc(ci). Reverts are of the original type or misc chores with impact - not a disconnected separate type - and indicated in the commit title.

    We develop in branches, and are free to be messy until we found and implemented a solution at which point we clean up commits to an intentional, documented changeset (using Git interactive rebase with squashing etc).

    We use a semi-linear history, so once a changeset is approved we rebase and merge with a merge commit - so we only have at most one merged parallel branch in the history tree. The generated changelog only considers merge commits - where the changeset is documented as a whole (same title and description as the merge/review request).

  • malloc@programming.dev
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    I follow this format:

    brief description
    
    - change1
    - change2
    
    <reference to issue, if applicable>
    

    I add the issue number since most decent issue trackers with integrated VCS (ie, github, bitbucket + jira) will automatically hyperlink it to the actual issue

  • stoehraj@midwest.social
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    Most of mine tend to follow this format:

    filename: brief description
    
    More in-depth description and rationale if needed
    

    It’s not often where I will modify multiple files within a single commit, but if I do, I will typically use a section or subsystem name rather than a single filename.