4 ms·

I agree mostly but recommend avoiding rebase at all costs at all times always and always prefer merge. Rebase is pure evil plain and simple.

computerfriend 3y ago
I rebase constantly and I love it. To each their own, I guess.
- tylerscott 3y ago
  I do as well and I also cherry pick a lot specifically with —no-commit to pull together disparate ideas from various sources. I am always fascinated when git usage comes up in threads because there are so many ways people use it that differ from my own and we all seem to find value in it!
okeuro49 3y ago
I use rebase to roll up all my commits before submitting a PR. Don't see what the big deal is.
- quesera 3y ago
  That's the simple and safe use of rebase. Rolling up your local wip commits into a coherent story of one or a few clearer commits. The more-complicated but still safe use is to rebase your local branch on top of an advanced upstream before pushing. Some people prefer merge for this case, but it is somewhat impure. The problematic use of rebase is on pushed branches. Especially if you have collaborators.
  - SAI_Peregrinus 3y ago
    > The problematic use of rebase is on pushed branches. Especially if you have collaborators. Yep. As soon as you have a PR out, and have to address comments, you have a public branch and can't safely rebase it. So you can't roll those new changes in to the "clean" history, If upstream also has changes before your PR gets merged, you'll also have to add a merge commit anyway.
    - morelisp 3y ago
      This is a problem of GitHub, not Git. E.g. GitLab preserves comments as well across rebases as any commit changes. "Don't rebase public branches" is an easy way to say "if someone has built something on top your branch, don't rebase unless you expect them to also rebase." 90% of the time this is not actually harder than merging, though, and still produces a better history and more atomic commits. At this point I'm even only 99% firm on "never rebase master", as long as release tags are truly immutable.
- l72 3y ago
  The rebase crowd seems to be obsessed with it due to wanting linear history. In my opinion, the reason for all of this is due to how `git log` shows history. If you merge a branch, then every commit in the branch is now scattered among your mainline history, making it confusing to see what is going on. So, instead of fixing `git log`, you end up rebaseing (and possibly squashing) on top of the main branch, then doing a fast forward commit so you get a "clean, linear history". But, if git just change the default of `git log` to `git log --first-parent`, then so much of this would go away. Only top level commits (directly to the branch, fast-forward merged, or a merge commit) show up in the history. Now, let's say I have a branch that I've been working on for 2 weeks. I have 20+ commits. During that time, I've already needed to merge the main branch into my branch to keep it up to date several times. I can either rebase the whole thing, to clean up history, remove the merge commits from main, squash unnecessary changes, and so on, just so I can get a "clean" history in main, or, we can just do a merge commit bringing in my whole branch with a good commit message. I prefer the merge commit because it is then very easy to track _all_ of the changes made in my branch by a single commit. I can do a diff on the merge commit and see all changes. I can cherry-pick just the merge commit and bring in all the changes. If I need to break down what the original developer of the branch was doing, I can walk through all the sub-commits. There is no need for them to rewrite history and hide their workflow or their process. But again, the problem is, by default, `git log` shows this as a huge mess, whereas `git log --first-parent` would _only_ show the merge commit, and would hide all the child commits that happened in the branch. After all, the top level merge commit is what is important, we only care about the subcommits when we need to dig in.
  - jrmg 3y ago
    I don’t think ‘linear history’ captures everything. In the orgs I’ve worked in, it was important that mainline always (bugs notwithstanding) always be ‘runnable’. Many people (myself included) will happily commit in-progress changes to branches they’re working on. If these in-progress changes get into the mainline branch - even as a result of a merge - they become part of its history and break the ‘always runnable’ property.
    - Nullabillity 3y ago
hedora 3y ago
Merge breaks your history. Most people start where you are, then eventually realize that merge is actually non-understandable, and switch to rebase. Hint: “git rebase -i HEAD~3” is your friend. So is “git bisect”.
- kingdomforgit 3y ago
  > Most people start where you are I've used almost every source control system known to humans the past several decades and git for over a decade. I've heard the git rebase preachers. I tried to get onboard with rebase. All who read, avoid rebase at all costs at all times, always.
  - mixmastamyk 3y ago
    A bit overstated but yes. Merge squash works every time. Rebase in my experience at work led to inexplicable conflicts several times I tried. When that happens the rebase preachers will be nowhere to be found, and you’re on your own.
    - avgcorrection 3y ago
      > Merge squash works every time. Which is a particular kind of rebase except the final commit gets cherry-picked to the target branch (instead of rewriting the original branch).
    - turtles3 3y ago
      > Merge squash works every time. Unless you've already started a follow-up branch before the first gets merged (eg. Waiting for QA, PO review etc.) Then you at minimum will need to rebase your second branch after the first is merged. Not a disaster but it adds overhead.
      - mixmastamyk 3y ago
        Never did that exactly. Think I've either, started a new branch from the waiting one or, started a new branch from the main and then pulled from the older feature branch. Have no recollection of any problems, but it is rare enough to not have tried it recently.

computerfriend 3y ago

I rebase constantly and I love it. To each their own, I guess.

tylerscott 3y ago
I do as well and I also cherry pick a lot specifically with —no-commit to pull together disparate ideas from various sources. I am always fascinated when git usage comes up in threads because there are so many ways people use it that differ from my own and we all seem to find value in it!

okeuro49 3y ago

I use rebase to roll up all my commits before submitting a PR. Don't see what the big deal is.

quesera 3y ago
That's the simple and safe use of rebase. Rolling up your local wip commits into a coherent story of one or a few clearer commits. The more-complicated but still safe use is to rebase your local branch on top of an advanced upstream before pushing. Some people prefer merge for this case, but it is somewhat impure. The problematic use of rebase is on pushed branches. Especially if you have collaborators.
- SAI_Peregrinus 3y ago
  > The problematic use of rebase is on pushed branches. Especially if you have collaborators. Yep. As soon as you have a PR out, and have to address comments, you have a public branch and can't safely rebase it. So you can't roll those new changes in to the "clean" history, If upstream also has changes before your PR gets merged, you'll also have to add a merge commit anyway.
  - morelisp 3y ago
    This is a problem of GitHub, not Git. E.g. GitLab preserves comments as well across rebases as any commit changes. "Don't rebase public branches" is an easy way to say "if someone has built something on top your branch, don't rebase unless you expect them to also rebase." 90% of the time this is not actually harder than merging, though, and still produces a better history and more atomic commits. At this point I'm even only 99% firm on "never rebase master", as long as release tags are truly immutable.
l72 3y ago
The rebase crowd seems to be obsessed with it due to wanting linear history. In my opinion, the reason for all of this is due to how `git log` shows history. If you merge a branch, then every commit in the branch is now scattered among your mainline history, making it confusing to see what is going on. So, instead of fixing `git log`, you end up rebaseing (and possibly squashing) on top of the main branch, then doing a fast forward commit so you get a "clean, linear history". But, if git just change the default of `git log` to `git log --first-parent`, then so much of this would go away. Only top level commits (directly to the branch, fast-forward merged, or a merge commit) show up in the history. Now, let's say I have a branch that I've been working on for 2 weeks. I have 20+ commits. During that time, I've already needed to merge the main branch into my branch to keep it up to date several times. I can either rebase the whole thing, to clean up history, remove the merge commits from main, squash unnecessary changes, and so on, just so I can get a "clean" history in main, or, we can just do a merge commit bringing in my whole branch with a good commit message. I prefer the merge commit because it is then very easy to track _all_ of the changes made in my branch by a single commit. I can do a diff on the merge commit and see all changes. I can cherry-pick just the merge commit and bring in all the changes. If I need to break down what the original developer of the branch was doing, I can walk through all the sub-commits. There is no need for them to rewrite history and hide their workflow or their process. But again, the problem is, by default, `git log` shows this as a huge mess, whereas `git log --first-parent` would _only_ show the merge commit, and would hide all the child commits that happened in the branch. After all, the top level merge commit is what is important, we only care about the subcommits when we need to dig in.
- jrmg 3y ago
  I don’t think ‘linear history’ captures everything. In the orgs I’ve worked in, it was important that mainline always (bugs notwithstanding) always be ‘runnable’. Many people (myself included) will happily commit in-progress changes to branches they’re working on. If these in-progress changes get into the mainline branch - even as a result of a merge - they become part of its history and break the ‘always runnable’ property.
  - Nullabillity 3y ago

hedora 3y ago

Merge breaks your history. Most people start where you are, then eventually realize that merge is actually non-understandable, and switch to rebase. Hint: “git rebase -i HEAD~3” is your friend. So is “git bisect”.

kingdomforgit 3y ago
> Most people start where you are I've used almost every source control system known to humans the past several decades and git for over a decade. I've heard the git rebase preachers. I tried to get onboard with rebase. All who read, avoid rebase at all costs at all times, always.
- mixmastamyk 3y ago
  A bit overstated but yes. Merge squash works every time. Rebase in my experience at work led to inexplicable conflicts several times I tried. When that happens the rebase preachers will be nowhere to be found, and you’re on your own.
  - avgcorrection 3y ago
    > Merge squash works every time. Which is a particular kind of rebase except the final commit gets cherry-picked to the target branch (instead of rewriting the original branch).
  - turtles3 3y ago
    > Merge squash works every time. Unless you've already started a follow-up branch before the first gets merged (eg. Waiting for QA, PO review etc.) Then you at minimum will need to rebase your second branch after the first is merged. Not a disaster but it adds overhead.
    - mixmastamyk 3y ago
      Never did that exactly. Think I've either, started a new branch from the waiting one or, started a new branch from the main and then pulled from the older feature branch. Have no recollection of any problems, but it is rare enough to not have tried it recently.