• Jesus_666@feddit.de
    link
    fedilink
    arrow-up
    17
    ·
    edit-2
    7 months ago

    I use interactive rebases to clean up the history of messy branches so they can be reviewed commit by commit, with each commit representing one logical unit or type of change.

    Mind you, getting those wrong is a quick way to making commits disappear into nothingness. Still useful if you’re careful. (Or you can just create a second temporary branch you can fall back onto of you need up your first once.)

    • bamboo@lemmy.blahaj.zone
      link
      fedilink
      English
      arrow-up
      3
      ·
      7 months ago

      This 100%. I hate getting added to a PR for review with testing commits in the history, and I’m expected to clean those up before merging into main.

      • Zangoose@lemmy.one
        link
        fedilink
        arrow-up
        3
        arrow-down
        1
        ·
        7 months ago

        I feel like squash and merge on GitHub/GitLab is nicer for that anyway though, it makes the main branch so much cleaner automatically

        • dejected_warp_core@lemmy.world
          link
          fedilink
          arrow-up
          1
          ·
          7 months ago

          If you’re using “trunk-based development” (everything is a PR branch or in main), this works great.

          If you’re using GitFlow, it can make PRs between the major prod/dev/staging branches super messy. It would be nice if GitHub would let you define which merge strategies are allowed per-branch, but that’s not a thing (AFAIK). So you’re probably better off not squashing in this situation.