you are viewing a single comment's thread
view the rest of the comments
[–] 15 points 4 months ago (2 children)

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

  • source
  • parent
  • hideshow 4 child comments
  • [–] 5 points 4 months ago (1 child)

    Haha same. But that's why you do it in another branch, and then squash-merge.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 2 points 4 months ago (2 children)

    I like squash merge on small changes, but when larger code changes are there it becomes a huge commit which is difficult to review if you ever have to go back.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 1 point 3 months ago

    If the squash merge is too big to review then that change should have been broken up into multiple separate changes. Regardless whether you’re using pull requests or some equivalent or directly merging feature branches, if “one unit of work” is too much to review when squashed, then your unit of work is too big and needs to be split up. A unit of work should always be reviewable as a whole.

  • source
  • parent
  • [–] 1 point 4 months 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.

  • source
  • parent