![]() ![]() You can also have your rebase replay on something other than the rebase branch. Rebasing replays changes from one line of work onto another in the order they were introduced, whereas merging takes the endpoints and merges them together. Note that the snapshot pointed to by the final commit you end up with, whether it’s the last of the rebased commits for a rebase or the final merge commit after a merge, is the same snapshot - it’s only the history that is different. That way, the maintainer doesn’t have to do any integration work - just a fast-forward or a clean apply. In this case, you’d do your work in a branch and then rebase your work onto origin/master when you were ready to submit your patches to the main project. Often, you’ll do this to make sure your commits apply cleanly on a remote branch - perhaps in a project to which you’re trying to contribute but that you don’t maintain. If you examine the log of a rebased branch, it looks like a linear history: it appears that all the work happened in series, even when it originally happened in parallel. There is no difference in the end product of the integration, but rebasing makes for a cleaner history. Now, the snapshot pointed to by C3' is exactly the same as the one that was pointed to by C5 in the merge example. Rebasing the change introduced in C3 onto C4.Īt this point, you can go back to the master branch and do a fast-forward merge (see Figure 3-30).įigure 3-30. Figure 3-29 illustrates this process.įigure 3-29. It works by going to the common ancestor of the two branches (the one you’re on and the one you’re rebasing onto), getting the diff introduced by each commit of the branch you’re on, saving those diffs to temporary files, resetting the current branch to the same commit as the branch you are rebasing onto, and finally applying each change in turn. In this example, you’d run the following: $ git checkout experimentįirst, rewinding head to replay your work on top of it. With the rebase command, you can take all the changes that were committed on one branch and replay them on another one. However, there is another way: you can take the patch of the change that was introduced in C3 and reapply it on top of C4. Merging a branch to integrate the diverged work history. It performs a three-way merge between the two latest branch snapshots (C3 and C4) and the most recent common ancestor of the two (C2), creating a new snapshot (and commit), as shown in Figure 3-28.įigure 3-28. The easiest way to integrate the branches, as we’ve already covered, is the merge command. If you go back to an earlier example from the Merge section (see Figure 3-27), you can see that you diverged your work and made commits on two different branches.įigure 3-27. In this section you’ll learn what rebasing is, how to do it, why it’s a pretty amazing tool, and in what cases you won’t want to use it. In Git, there are two main ways to integrate changes from one branch into another: the merge and the rebase. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |