Rebase is copying a series of commits and pasting them onto somewhere else. By default it will copy commits and apply them onto the new upstream.

In other words, go from

            old                 your
           master              master
    ----*----*----A----B----C----D
              \        
               \          new
                \        master
                 \----*----*

to

            old               your old
           master              master
    ----*----*----A----B----C----D
              \        
               \          new                 your
                \        master              master
                 \----*----*----A'---B'---C'---D'

Interactive rebase allows you to choose to reorder, rename, combine or drop those commits A, B, C, D as they are applied to new master.

Rebase is just replaying the diff associated with each commit. It’s like a batch cherry-pick and that itself might be a conceptually more straightforward place to start.

This is great. IMO “replay” is a much better description than “copy.”

Technically more appropriate than copy as a commit is immutably wedded to its history by the chain of hashes preceding it.

FYI replay is the term used in the git docs, which otherwise make little sense.

I gave up. I determined some of us are just too stupid to do quantum physics or rebase in git without destroying our branch. I'm one of those people.

FWIW Git is harder to understand than basic quantum mechanics IMO.

The latter has been optimized with good notation and has a fairly simple structure, whereas Git is a beautiful idea wrapped in an API from hell

The most useful way for me to think about a rebase is "replay my commits over an updated branch, as though I started coding when those updates had already happened"

So if you check out on day 0 and rebase on day 5, then it becomes "pretend I started coding on day 5 in the first place, and let me correct any contradictions (conflicts) as though I was making those decisions as I was making each commit".

I still struggle but this helps me conceptualize it.

For me it's the other way around. I mean, it's like one of the few commands which says what it does: re-base. Makes all kind of sense to me: take what you have and put it on top of something else. So same as a bunch of cherry-picks, etc. It was one of the first concepts I undesrtood. Merge on the other hand I understand as well but it leads to graphs I can't understand without spending some time looking at.

Someone will correct me, hopefully, if I'm wrong:

Rebase means moving the branch point of your feature branch to later on the main branch.

Let's say you create feature branch foo from main on 2021-08-01. You do work. Others do work and add them to main. On 2021-09-18, you rebase foo onto main. This has the effect of re-writing history! There's no longer a branch point at 08-01, it's been moved to 09-18.

https://www.atlassian.com/git/tutorials/merging-vs-rebasing

Rebase is not always the best option. I personally prefer merging, and that has worked for 100% of situations I've found myself in so far in my DevOps career.

> Someone will correct me, hopefully, if I'm wrong:

> Rebase means moving the branch point of your feature branch to later on the main branch.

It refers to a more generic action/set of actions, where this description is one possible end result. Granted this is probably the most common use, and the name "re-base" definitely fits this usage best.

The more generic action is something like "take a set of commits in one place in the git history, and reapply them somewhere else in the git history, optionally dropping or rearranging some of them in the process".

It's strangely wonderful to me that people can have so many different ways of explaining this action/concept. Your description is definitely more accurate than mine :)

Tip: Create a new branch before you do the rebase, if you fuck up the rebase with bad merges or dropped commits it's easier (i.e. more intuitive) to unfuck by just using the backup branch you made prior to your rebase instead of messing around with `git reflog`.

rebase cherry-picks more than one commit, as in "git reset c; for commit in a..b; do git cherry-pick $commit; done". With sensible defaults for a, b and c, they can often be left out.