5 ms·

Exactly. I use basic git daily, but I'm still confused about rebase.

gfodor 5y ago
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.
- mhh__ 5y ago
  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
frutiger 5y ago
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.
- deleted 5y ago
  [deleted]
stinos 5y ago
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.
rusk 5y ago
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.
- grayclhn 5y ago
  This is great. IMO “replay” is a much better description than “copy.”
  - rusk 5y ago
    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.
xorcist 5y ago
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.
bloopernova 5y ago
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 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.
- Izkata 5y ago
  > 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".
  - bloopernova 5y ago
    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 :)
and0 5y ago
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.
bentcorner 5y ago
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`.

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.

mhh__ 5y ago
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

frutiger 5y ago

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.

deleted 5y ago
[deleted]

stinos 5y ago

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.

rusk 5y ago

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.

grayclhn 5y ago
This is great. IMO “replay” is a much better description than “copy.”
- rusk 5y ago
  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.

xorcist 5y ago

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.

bloopernova 5y ago

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

Izkata 5y ago
> 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".
- bloopernova 5y ago
  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 :)

and0 5y ago

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.

bentcorner 5y ago

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`.