3 ms·
Rebase is simple. It's "take these commits, and apply them one by one on top of another branch". So let's say your main development line is the "main" branch.
by dale_glass 3y ago
Rebase is simple. It's "take these commits, and apply them one by one on top of another branch".
So let's say your main development line is the "main" branch. You start working on "bugfix", so you branch-off from "main". You do this on November 1.
So you make commits: "Fix bug". Then "Remove debug code", then "Rename X to Y". Now it's 10 days later.
Say a coworker is doing some other work at the same time, and just merged this into "main". You want to make sure that after that, everything still works properly. Maybe somebody changed something that makes the code you wrote no longer work, because somebody happened to fix a typo in a function's name or something, and you wrote your code against the old name which just ceased to exist.
So you do "git rebase main". What you're telling Git is "take the commits I made during the last 10 days, and apply them on top of the current main". It's like if you created a new branch then just applied the commits one by one by hand.
You can do this as often as you want, so if you've got some experimental refactor that takes you a month you can keep on rebasing daily to make sure that if there's any conflicts you have to deal with, you deal with it a little at a time, instead of having to figure out how to square a month of your work with a month of the rest of the project's work once you're done.
With this once you merge this into master, you get a "fast-forward" merge, which looks as if you were working on top of master all along. Instead of a single merge commit you see all 10 commits you made for the branch.
You can also do an "interactive rebase", where instead of having the process automated you can make decisions about each commit individually. This allows you to rename, merge, or discard commits. Like you've got 10 embarrassing looking commits where you just poke stuff at random in hopes of that it'll finally work? You can make them disappear entirely, or merge them all into one commit.
- recursive 3y agoNot who you're responding to, but I also understand merge more readily than rebase. Your explanation doesn't really help. Applying a commit "on another branch" isn't really well defined in my mind. In my understanding, a commit consists of one or more parent commits, and the complete state of a tree, including the entire contents of all the files in it. Maybe there are other ways to be confused, but all of the uncertainty has been shoved into that simple phrase "apply a commit on another branch". What does that actually mean?
- dale_glass 3y ago> "apply a commit on another branch". What does that actually mean? Calculate the difference between the commit and its parent, and repeat that change against another branch. So, like git log of your work over 10 days, git show each commit individually, then apply each patch that generates against the latest code.
- pertymcpert 3y agoOf course it's defined, even git knows what it means because that's what cherry-pick does.
- recursive 3y agoSo cherry-pick is actually merge, and rebase is actually cherry-pick? Everything is merge.
- pertymcpert 3y agoNo, cherry-pick is cherry-pick. Rebase is a composite action which includes one or more cherry-picks.
- ecnahc515 3y agoHave you ever used git cherry-pick? Git rebase is if you were loop over each commit (bottom to top) and run `git cherry-pick` on each commit separately. If you haven't used git cherry-pick, then it is basically a shortcut for `git show $REF | git apply -`, where the short cut is the simplest form of using git, you have a patch (via git show) and you want to apply it to your local checkout.
- jkubicek 3y agoRebasing isn't that hard, but you also spent 8 paragraphs explaining it. Explaining merging just takes one paragraph: Copy all the changes from the main branch into my branch, if someone changed the same line that I changed, then create a merge conflict and manually figure out which change is right.
- dale_glass 3y agoIt's a matter of taste really, there are pros and cons to both. Rebase also can produce merge conflicts when doing the rebase. Sometimes that makes resolving them easier and sometimes harder.
- AlotOfReading 3y agoTheir explanation is one sentence. The rest is context, examples, and useful extensions of the basic idea (e.g. interactive rebases).