I basically only use git merge like Theo from T3 stack. git rebase rewrites your commit history, so I feel there’s too much risk to rewriting something you didn’t intend to. With merge, every commit is a real state the code was in.

  • spartanatreyu@programming.dev
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    It’s not rebase vs merge, it’s rebase AND merge.

    Commit your changes into logical commits as you go.

    Then just before submitting a pull request, review your own code. That includes reviewing your own commits too, not just the code diff.

    Use rebase to:

    • Swap commits so that related changes are together
    • Edit your commit messages if you find a mistake or now have a better idea of what to put in your messages
    • Drop any useless commits that you just end up reverting later
    • Squash any two commits together where the first was the meat of desired change and the second was the one thing that you forgot to add to that commit so you immediately followed it up with another commit for that one missing thing.

    Then, and only then, after you have reviewed your own code and used rebase to make the git history easier to read (and thus make it easier to review), then you can submit a pull request.

  • canpolat@programming.devM
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    It’s correct that rebase rewrites history, but it’s important to identify when it’s not acceptable. If you are working on a branch that is shared by others (typically main), you should never use rebase. But it’s an acceptable practice when used properly. I use rebase on my feature branches whenever necessary. If it fell behind the main branch I do git fetch followed by git rebase origin/main, resolve the merge conflicts and keep coding. I also use interactive rebase when I need to tidy things up before merging the feature branch to main.

  • RandomDevOpsDude@programming.dev
    link
    fedilink
    English
    arrow-up
    0
    ·
    1 year ago

    I rebase my dev branches on main to get rid of garbage commit messages due to me being lazy.

    Squash and merge PRs into main, no merge commits allowed.

    I think there are reasonable arguments for allowing rebase and merge to main, but it often doesn’t apply for me.

    Merge commits in main will break a lot of out of the box GitOps tools.

    • AnyOldName3@lemmy.world
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      I’m okay with squashing consecutive silly commits before a merge, but having worked on a codebase that used the policy described above for a decade before I got there, I really, really hate it. Git blame and other history inspection tools are nearly totally useless. I’ll have access to commit messages, but when things have been shuffled around feature branches for a while, they end up concatenated into mega commits with little hope of figuring out why anyone did anything or what they were thinking when they did it. Some of this might be mitigated if stale branches weren’t deleted, but people don’t like stale branches.

      If there are genuinely Git tools that can’t handle merge commits in <current year>, I’d be surprised if they didn’t have Fisher Price or Hasbro written on the side.