• RonSijm
    link
    fedilink
    arrow-up
    1
    ·
    9 months ago

    I’ve never really needed to use rebase, but my workflow is probably kinda weird:

    • I just start programming from the dev branch
    • At some point once I have stuff to commit, I do git checkout -b new_feature_branch, and so move my changes to a different branch
    • I commit a bunch of stuff into that branch, usually just with commit messages of “working on new_feature”
    • Once I’m done, and I have - lets say - 10 commits in that branch:
    • I do git reset head~10 meaning all 10 commits are reverted into staged changes
    • I now do 1 new commit of all the changes, with a decent commit message to explain the new feature
    • I git push -f the new commit back to origin (of feature branch)
    • I PR the feature branch to dev, and merge it

    It works pretty well for me, but I was told its weird, and I should rebase instead

    • zygo_histo_morpheus
      link
      fedilink
      arrow-up
      1
      ·
      9 months ago

      The benefit with rebase is if you want to have maybe 4 commits insteadd of 10. When reviewing a large pr, I find that it’s helpfull if it’s broken up into a couple of coherent commits so that I can review it commit by commit. It’s easier to follow the logic of why something is being changed if it’s associated with a specific commit.

      Sometimes squashing the entire commit is the right choice, in which case you can do what you’re doing or use some built in feature to do that.

    • Piatro
      link
      fedilink
      English
      arrow-up
      1
      ·
      9 months ago

      You do you. People generally discourage rebase because it rewrites history but that’s what you’re doing anyway. You can achieve the same result with revase --interactive and following the instructions to squash all your in progress commits into a single commit. That way you don’t have to figure out how many commits between your in progress and dev(for your reset command) as the rebase will handle it for you.