We can take the changes on ‘client’ that are not on ‘server’ and replay them on our master branch by using the –onto option to ‘git rebase’. Then we decide that we want to merge our client side changes into our mainline for a release but we want to hold off on the server side changes until it is further tested. Then we branched off of that to make the client side changes (‘client’) and committed a few times. We branched a topic branch (‘server’), say to add some server-side functionality to our project and made a few commits. Let’s take a history like this, for example. You can also have your rebase replay on something other than the rebase branch. In this case, the contributor would do their work in a branch, then rebase their work onto ‘origin/master’ when they are ready to submit their patches to the main project so the maintainer doesn’t have to do any integration work, it’ll just be a fast forward or a clean apply. Often one will do this to make sure that commits they did will apply cleanly on a remote branch, maybe to a project they are trying to contribute to that they are not the maintainer of. If you look at the log of a rebased branch, it just looks like a linear history, like all of the work happened in series, even when it actually happened in parallel. Now the snapshot pointed to by C3’ is exactly the same as the one that was pointed to by C5 in the ‘merge’ example, so there is not really any difference in the end product of the integration, but it does make for a cleaner history. It works by going to the common ancestor of the two branches (the one you are on and the one you are rebasing onto), getting the diff introduced by each commit of the branch you are on, saving them to temporary files, then moving the branch over to the rebasing branch and applying each change in turn.Īt this point, you can go back to the master branch and do a fast-forward merge. In this example, we would run this: $ git checkout experimentįirst, rewinding head to replay your work on top of it. In Git, this is called rebasing - with the ‘rebase’ command, you can take all of the changes that were committed on one branch and replay them on another one. However, there is another way, which is to take the patch that was introduced in C3 and re-apply it on top of C4. This performs a 3-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). The easiest way to integrate them, which we’ve already covered, is the merge command. If we go back to an earlier example from the Merge chapter, we can see that we diverged our work and made commits on two different branches. In this section we will learn what ‘rebasing’ is, how to do it and in what cases it may not be a good idea to. 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 |