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
    26
    ·
    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.

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

      love this approach and it’s what I usually use. I also don’t rebase after opening a PR (GitHub) because force pushing ruins reviewer context in the GH UI. so after the PR is open I merge main/master in instead of rebasing.

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

      Yeah, doing a git rebase -i --autosquash prior to opening a PR is good practice. (Also folks should look into autosquash if they haven’t heard of it.)

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

      This sounds like a really good work flow. I’ve only started working professionally with git only few months ago when I switched jobs to gamedev (for some reason, even though I worked for three years as a pentester in cybesecurity company they literally didnt use VCS for anything), so I still don’t have proper git workflow of my own, and this sounds way better. Thanks!

      Before I had to start making PRs, my whole git experience on personal projects was git add . ; git commit; git push;

  • canpolat@programming.devM
    link
    fedilink
    English
    arrow-up
    13
    ·
    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.

    • Baldur Nil@programming.dev
      link
      fedilink
      English
      arrow-up
      5
      ·
      edit-2
      1 year ago

      That’s what I do as well. Where I work, it’s common to have branches that take long to be ready for merge (because of bureaucracy), but because of many teams working on the same app, the upstream branch changes quite often.

      I see some coworkers make just a few changes and a lot of times reverting stuff so the diff might be 1 line in the end, but the commit history is a mess of 30 commits of merges, triggering pipelines and undone stuff that was discarded later.

      Then sometimes they have to find where they changed something they broke their feature and it’s a hell time to find what commit actually has any relevance for the final result.

  • RandomDevOpsDude@programming.dev
    link
    fedilink
    English
    arrow-up
    6
    ·
    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
      4
      ·
      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.

  • TheAgeOfSuperboredom@lemmy.ca
    link
    fedilink
    English
    arrow-up
    6
    ·
    1 year ago

    I’ll often commit half finished or outright broken code to a private branch for my own purposes. Then I’ll rebase before pushing to make the history make more sense to the team and get rid of fluff commits.

  • ozr@programming.dev
    link
    fedilink
    English
    arrow-up
    5
    ·
    edit-2
    1 year ago

    When “merging” in master/main before opening a pull request I always rebase any local commits I have, it does no harm but vastly reduces complexity of the commit tree - however, as soon as code from other branches enters the picture I merge

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

    Ideally I’m working on a short lived branch that only I’m working on in which case I do a rebase from origin/master where I also touch up the history in case there are any “forgot x in the previous commit” type of commits before doing a merge request. I won’t rebase code someone else might have pulled, and I’ll quit rebasing if I get any non-trivial conflicts .

  • funbike@programming.dev
    link
    fedilink
    English
    arrow-up
    4
    ·
    edit-2
    1 year ago

    Tbh, I hate both. I wish git recognized an attempt to sync with a parent branch without resulting in either altered history (rebase) or a difficult to view log graph (merge). I also hate that teams have to choose one or the other.

    It would be nice if all git graph UIs could easily exclude parent branch merges (with a checkbox). I wrote a shell script that did that, but not everyone used it of course.

    I rebase with parent branch until I create a PR. Hopefully, I’ll get reviews quickly and won’t have to sync with the parent branch before merging the PR into the parent. However, if the PR lives longer than I’d like and conflicts occur, I’ll merge from the parent branch into the local feature branch.

  • SuperNerd@programming.dev
    link
    fedilink
    English
    arrow-up
    5
    arrow-down
    2
    ·
    1 year ago

    Please never rebase after you open a pull request. It breaks the iterative workflow of code reviews – it makes it hard to see if issues brought up in comments were addressed or not.

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

      That depends on the PR tool. I don’t know how others work, but Azure DevOps handles rebases quite well (as long as you are rebasing to the target of your PR).

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

    The cases where you can use git pull --rebase have high overlap with the cases where git rebase is sane.

    The important thing is when to avoid doing git push --force (almost always; if your remote is a personal fork you theoretically could just create an infinite number of similar branch names for your rebases). Though there are edge cases involving local/SSH clones.

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

      What does git pull rebase do? If I understand it correctly, it pulls in the remote changes but rebases your changes to be on top of them, instead of merging the remote and local branch? What is the intended usage of it, it sounds like a lot better way how to pull, why not to use it as default pull?

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

        you pretty much should use it as the default pull. There are very few cases when you shouldn’t use it. Something like fetching from an upstream remote maybe.

      • GitProphet@lemmy.sdf.org
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 year ago

        Because rebasing changes the history, which would mess with other people’s copies of the same branch, wherefore it shouldn’t be default.

  • GitProphet@lemmy.sdf.org
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    1 year ago

    I use rebase only to clean up some commit messages, squash commits, etc. - essentially to clean up feature branches I wrote. But never rebase to ‘move’ my branch as if it originated from a different commit, because I don’t know necessarily know what changes have been introduced on the other branch (typically main/master), so rebasing on that would leave my commits in a state that they were never tested in, possibly broken / with unintended sideeffects. If I need changes from the other (main) branch in my feature branch (because of feature dependencies, or to fix merge conflicts), I merge it into my branch and can be sure that the commits created before that merge still behave the way they did before that merge - because they were not changed; this can’t be said for rebasing.