In fact, it allows you to rebase an arbitrary range of commits on top of another one. Git rebase -onto can go one step further in terms of precision. The Surgeon: git rebase -onto with 3 arguments In this example, in order to remove C and E from the sequence you would say git rebase -onto B E, or rebase HEAD on top of B where the old parent was E. Īnother scenario where this comes in handy is when you want to quickly remove some commits from the current branch without having to do an interactive rebase: Before AfterĪ-B-C-E-F (HEAD) A-B-F (HEAD) The syntax of git rebase -onto is then git rebase -onto. In other words, change the parent of E from D to F. Rebase the commit reachable from HEAD whose parent is D on top of F. In this case, we would say git rebase -onto F D. We're only interested in bringing F into our working branch while, at the same time, we don't want to keep D because it contains some incompatible changes. This is for scenarios where you need to be precise.įor example, let's imagine that we need to rebase HEAD precisely on top of F starting from E. It grants you exact control over what is being rebased and where.
Git rebase -onto allows you to rebase starting from a specific commit. The Precise: git rebase -onto with 2 arguments change its parent) on top of the latest commit reachable from branch but not from HEAD, that is G. Saying git rebase branch will take D, that is the first commit after the branching point, and rebase it (i.e. In this example, F and G are commits that are reachable from branch but not from HEAD.
Before AfterĪ-B-C-F-G (branch) A-B-C-F-G (branch) This is the most common case of rebasing and arguably the one that requires less planning up front. Git rebase is going to rebase the branch you currently have checked out, referenced by HEAD, on top of the latest commit that is reachable from but not from HEAD. If you're interested in the difference between git rebase and git rebase -onto read on.
Or rebase B on top of A starting from the commit that is the parent of B referenced with B^ or B~1. You can also do this for a single pull using git pull -rebase.The correct syntax to rebase B on top of A using git rebase -onto in your case is: git checkout B You should never use the rebase approach if someone else has already pulled from your master branch.įinally, note that you can actually set up git pull for a given branch to use rebase instead of merge by setting the config parameter branch.rebase to true. The rebase rewrites your history, making it look as if you had committed on top of origin's new master branch ( R), instead of where you originally committed ( H). The content of your work tree should end up the same in both cases you've just created a different history leading up to it. If on the other hand you did the appropriate rebase, you'd end up with this: - o - o - o - H - P - Q - R - A' - B' - C' (master) If you merge at this point (the default behavior of git pull), assuming there aren't any conflicts, you end up with this: - o - o - o - H - A - B - C - X (master)
After the fetch, things look like this: - o - o - o - H - A - B - C (master) So let's suppose you're in the common case - you've done some work on your master branch, and you pull from origin's, which also has done some work. It should be pretty obvious from your question that you're actually just asking about the difference between git merge and git rebase.
0 kommentar(er)
