807
Well well well. (lemmy.ml)
submitted 1 year ago by to c/programmer_humor@programming.dev
130 comments fedilink hide all child comments
 

Yeah learned this the hard way.

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

Same… My usual strategy: rebase, if conflict abort and merge, if no conflict continue; merge always with explicit commits to master / main (no fucking squashing); keep task references in branch names and commit messages.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 1 point 1 year ago (3 children)

    Same, but typically I will just resolve the conflicts during the rebase. Makes for cleaner commit history. Merge commits are for combining multiple big unrelated pieces of work together, where rebasing would be too annoying (let's say 100s of commits each).

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 1 point 1 year ago* (2 children)

    In my cases I has to solve same code conflicts multiple times during a rebase, so I just don't try them when hit with conflicts.

    I fail to see the benefits of "clean" git history

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 1 year ago (1 child)

    In my cases I has to solve same code conflicts multiple times during a rebase, so I just don’t try them when hit with conflicts.

    Yeah if you have two branches, both with a bunch of commits which all modify the same areas of code, and reordering the commits doesn't help, I can see how it is easier to merge.

    I fail to see the benefits of “clean” git history

    Well, if the commit history is clean and mostly linear, it's much easier to read, understand and review. git blame will also be much nicer which is really important for debugging big codebases. Of course it's a tradeoff, as usual.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •