![]() ![]() Now to rebase onto the latest master we’ll run: git rebase masterĪnd that’s it. So we’ve got the commit I just created, 00e444061, in which I added a new file, and its parent commit, bb25634af, which is 2 commits behind master. On my machine it looks like this: $ git log -oneline -2 00e444061 (HEAD -> mytestbranch) Added a new file bb25634af Merge pull request #2398 from jsmith/master Now that you’ve got some changes in your branch, let’s rebase it onto master, but first let’s run git log -oneline -2 and note the output. Doing something straightforward like adding a file or editing the README is fine. You might want to avoid changing a file that has a high chance of having a merge conflict so as to avoid dealing with merge conflicts for your first rebase, but it’s up to you. touch new_file git add new_file git commit -message "Added a new file"Īny changes are fine. Now let’s make some changes to the repo and make a commit. The ~2 tells git to create the branch not at master, but 2 commits behind. You can do this with one command with git checkout -branch mytestbranch master~2 Let’s start with creating a branch a couple of commits behind master. We won’t be making any destructive changes. For these exercises, feel free to either make a test repo or go ahead and do them within a repo you frequently work with. OK enough theory, let’s bust out our terminals and crank out a few commands. When you rebase, you still have to solve the same merge conflicts, but instead of solving them in a merge commit, you solve them in the commits as they’re being re-applied (if the rebase process detects a merge conflict, it’ll stop and let you resolve it before continuing), and so when you go back to look at the diffs of the individual commits, they now make sense when you’re comparing them to master, as opposed to having some lines missing because they’re added in a future merge commit. I find rebasing especially helpful when there are merge conflicts - when you merge, you have to solve the merge conflicts in the merge commit, and so when you look through your history to find the sum total of changes needed to implement your feature or fix your bug, you need to look through both the original commits and the merge commit. Merging master into hotfix as opposed to rebasing I personally find it much easier to think about my branches when they’re in this state, as opposed when I’ve merged changes from master and created a sort of “railroad track” in my commit history: “Reapplying” in this case means that we take the diff between the first commit of hotfix and its original “base tip” and apply it to the new “base tip”.Īnother way to think about rebasing is that when you’ve rebased a branch, it’s as if you had just now created your branch off of this latest master and done all of your work on top of it. Frankly “base tip” is a bit of a strange word, and it might make more sense if you think of rebasing as “re-parenting”, because you’re changing the parent of either one commit or a series of commits. ![]() So the 3 commits from the hotfix branch were “reapplied” on top of “another base tip” which in this case is the head of the master branch, as opposed to the previous “base tip” which was 2 commits behind the head of the master branch. Let’s say you have a branch/repo that looks like this: What does that mean? Let’s bring in some visuals. ![]() What is rebasing? The git documentation states that it is “reapplying commits on top of another base tip”. This ultimately allows you to change the way you think and talk about commits - you can talk about “the” commit where a bug was fixed or “the” commit where a feature was introduced, but perhaps more importantly for right now it’ll let you clean up those embarrassing commit histories of trying a million times to get the build to pass on the server. Squashing is the process of taking two or more existing commits and combining them into one commit. Rebasing can be used instead of merging to bring in changes from master or another branch and results in a much cleaner and more intuitive branch history. In this article we’ll be talking about rebasing and squashing. Of course, those who have it all under control and just want to learn more about what git offers are welcome too! This article is for those who are comfortable with basic git operations and concepts like staging, committing, pushing, pulling, and merging, but who still find themselves struggling through the occasional merge conflict, or creating embarrassingly long commit histories (“fix typo”, “actually fix typo”, “remove unintentionally committed changes”), or feeling unsure about what their branch history looks like after a merge, or two, or three. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |