Hey guys, today I'm the one trying to learn, so I want to see if anybody can explain to me, what is git rebase, and how to use it.
For further actions, you may consider blocking this person and/or reporting abuse
Hey guys, today I'm the one trying to learn, so I want to see if anybody can explain to me, what is git rebase, and how to use it.
For further actions, you may consider blocking this person and/or reporting abuse
madina1575 -
Christopher Glikpo ⭐ -
Oleg -
keploy -
Top comments (8)
The simple explanation is that each commit in
git
has one or more 'parents', which are commits that come logically before it in the change history, andgit rebase
changes what the parent of the base commit (that is, the commit that you started the branch from) in a branch is. Essentially, if you think of each commit as a folder in the filesystem, it's parent is the folder that contains it, andgit rebase
is equivalent to moving it into a different folder (of course, with lots of extra stuff to sanely handle conflicts).This is useful for a number of things:
git rebase A B
(or, if you have branch B checked out,git rebase A
). In many workflows, this is the preferred way of updating branches that you have not published anywhere because it helps keep the history simple. This is about 95% of what most people will ever needgit rebase
for.git rebase --onto A B C
. This covers a significant majority of the remaining 5% of what most people will ever need it for.git rebase
can take tags or even commits instead of branch names, you can use it to move individual commits or sequences of consecutive commits from one branch to another with thegit rebase --onto
syntax. This is useful when you end up developing a fix for an existing bug as part of developing a new feature, and need to submit that fix separately from the new feature. Note however thatgit cherry-pick
plus a carefully craftedgit reset
is often preferred here, as it's a lot easier to get right than doing the same thing withgit rebase --onto
(and it's usually easier to fix if you get it wrong).git rebase
to remove a series of commits from further back in the history of a branch using thegit rebase --onto
syntax. This is not something that is frequently needed if you're doing your development work properly, but if you haven't published a branch yet, this may be preferable to reverting a prior commit in the branch as it will make the history more concise.git rebase -i
, also works with the the--onto
syntax, though that tends to be very confusing so it's generally not the best idea to do it in one step (you can alwaysgit rebase -i
and thengit rebase --onto
as two separate steps)). This is only very rarely needed in a vast majority of development workflows (especially if you're doing your development work right), but it lets you do very complex things like splitting a commit into multiple commits, merging a bunch of commits into one, reordering the commits on the branch, or even just running a given command in the working tree for each commit on the branch (useful for testing proper bisectability of a sequence of changes, which is a major reason thatgit rebase -i
exists in the first place).There is, however, one very big caveat to using
git rebase
. Because it modifies history, you have to use a force push whenever you rebase a branch and then have to update a remote copy of that branch. This plus the rewritten history makes it very difficult for others to update copies of that branch in any clones of the repository (it requires them to delete their local copy of the branch, re-fetch the refs for it from the remote, and then check it out again), especially if they have any local work based on it. As a result, the general advice is to avoid rebasing any published branches outside of situations that you've agreed with your coworkers that it's acceptable to do so.You may also want to look at
git cherry-pick
, which lets you copy commits from one place to another (unlikegit rebase
, which functionally moves commits).Woah !
Haha. Sarcasm :D ;)
Take your three favorite books and put them on top of the evergrowing pile of books to read so that even though you keep buying books your three favorite books will be fresh at the top of the pile
:-D
Rebase is another way to integrate changes from one branch to another. Rebase compresses all the changes into a single “patch.” Then it integrates the patch onto the target branch. Unlike merging, rebasing flattens the history because it transfers the completed work from one branch to another.
Rebase does no perform any flattening, unless you tell it to.
Okey dokey, I'm gonna take a different approach to answer this. A lot of folks are focusing on what pull --rebase does which is only a portion of how rebase works.
Imagine a group of friends standing around sharing a story. Each person adds their part to the story, then the next says, "Yeah, and then..." before adding their part. This is how git organizes commits, even branches.
Now, someone shows up to the group of friends, gets in the middle of them and says, "No no no, you got it all wrong!" And proceeds to tell everyone the entire story their way. This is what rebase does. It completely alters the story.
Rebasing is a desctuctive with few means to recover
You can alter the story in your head all you want before you speak it. Once you speak it though, you must never change it. In other words, you can rebase anything you've not pushed and you only mess yourself up. Once you push it though, you're altering everyone's story and that is extremely dangerous.
Well, did you ever play towers of hanoi when you were 5?
You're tasked with rebaseing your commits to a different peg. The difference is, you can take any number and apply them in any order to any peg.