• dudinax@programming.dev
    link
    fedilink
    arrow-up
    0
    ·
    9 months ago

    Merge. One of the values of a VCS is to preserve history in detail, and merge is the only method that does that. Also, it’s easy to foul a remote branch with the other methods if someone has already pushed changes to branch 1.

    • Ferk@kbin.social
      link
      fedilink
      arrow-up
      1
      ·
      9 months ago

      I feel it’s a balance. Each operation has a purpose.

      Rebasing makes sense when you are working in a feature branch together with other people so you rebase your own commits to keep the feature branch lean before you finally merge it into the main branch, instead of polluting the history with a hard to follow mess of sub branches for each person. Or when you yourself ended up needing to rewrite (or squash) some commits to clean up / reorganize related changes for the same feature. Or when you already committed something locally without realizing you were not on sync with the latest version of a remote branch you are working on and you don’t wanna have it as a 1-single-commit branch that has to be merged.

      Squashing with git merge --squash is also very situational… ideally you wouldn’t need it if your commits are not messy/tiny/redundant enough that combining them together makes it better.