Rebase onto develop11/16/2023 With all changes again integrated, Satoshi is ready to continue working on his topic branch.īelow is the final result from the rebase action. But then, instead of making a regular merge “ preserving history as it happened”, Satoshi can instead integrate all changes using rebase and hence “rewrite history”.īy rebasing feature-2 onto master Git will rewind and reapply the commits C5 and C6 one by one, straight onto C4, making it look like feature-2 was originally branched off the tip of Ada’s completed changes.Ĭheckout this 30-second animation to see the process in action: Animation illustrating the rebase workflow. Just as in the merge case, he must first ensure his local and remote branches are in sync before Satoshi can integrate the changes. With the basic merge workflow in mind, it’s time to look at the same example but from a rebase perspective. By merging the changes from “master” into “feature-2”, history is preserved as it happened and only merge commit “C7” is introduced.Ĭonfused by the moving HEAD pointer? Checkout this post on the subject! As you can see, the development history is preserved just as it happened, with only C7 added. With all changes merged into feature-2 Satoshi can now continue to develop the branch, finishing it off by merging it back into master whenever it’s completed.īelow is the final result from the merge action. Once master and o/master are in sync, Satoshi is ready to merge everything into his topic branch.Ĭheckout this 30-second animation illustrating the process: Animation illustrating the merge workflow. Before Satoshi is ready to merge Ada’s changes into feature-2, he must first update his local master reference, as it’s currently trailing behind. Let’s start with the most common workflow for integrating changes: merge. Satoshi now has two options to integrate Ada’s changes into his branch feature-2 - merge or rebase. Ada then completed feature-1 by merging it into master (creating merge commit C4). Looking at the example above, we see that the developers Ada and Satoshi initially created two topic branches ( feature-1 and feature-2), stemming from the same commit ( C1) on the master branch. Notice also that the local “master” branch (C1) currently trails behind its remote counterpart “o/master” (C4). Before we look at their inner workings to understand what this means, let’s start with an example! History graph viewed from the eyes of Satoshi, with remote “origin” aliased as “o” for convenience. In other words, the key difference between merge and rebase is that while merge preserves history as it happened, rebase rewrites it. Reading the official Git manual states that rebase " reapplies commits on top of another base branch”, whereas merge " joins two or more development histories together”. If you know how the actions work, feel free to skip to the comparison section. In this post, I’ll illustrate and highlight the differences between the two options and point out things to look out for when performing the actions.įirst, I’ll go through the two operations in isolation using animations, finishing with a side-by-side comparison. With git there are two main options for this, either you merge, or you rebase. Regardless of which branching strategy your project is using, integrating code changes between branches is something that you need to do almost daily. 7 min read Photo by Joey Kyber / Unsplash.
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |