• ranzispa@mander.xyz
    link
    fedilink
    arrow-up
    20
    ·
    1 day ago

    Sometimes you really don’t want to look over the commit history of your colleagues. As long as it’s a small feature, a single commit is a pretty good option.

    Rather than:

    • implemented X
    • forgot this
    • oh, this was not needed
    • now tests actually pass
    • oops
    • fixed this
    • should be ready
    • expr@piefed.social
      link
      fedilink
      English
      arrow-up
      7
      ·
      1 day ago

      It’s fine if the changes belong in a single commit. Otherwise, an interactive rebase to craft a clean, quality history before merging is much, much better.

    • Elvith Ma'for@feddit.org
      link
      fedilink
      arrow-up
      12
      ·
      1 day ago

      That’s basically my commit history for every repo where I need the pipeline to run to see if everything works.

      • ranzispa@mander.xyz
        link
        fedilink
        arrow-up
        1
        ·
        1 day ago

        When I do that I always have a Dev branch that I use as the production branch to run the actual calculations.

        When I get something working I merge it off, clean up the history a little bit, rebase main onto it and then rebase de onto main.