![]() This would result in the following scenario: In any case, if you want to move your branch to the head of the main branch, from your working branch you would run: git rebase main Maybe there is a bug fix that you need to build your feature, or another feature was added that will make the implementation of your feature better somehow. Let’s say you want to take advantage of some of those commits in the main branch. You have a few commits on to your branch, and, similarly, the main branch has also had a few commits merged in. Here you have a main branch, and your current working “feature” branch. If you are unfamiliar with git rebase, essentially what it does is allow you to say, “Move the start of my branch to the head of another branch.” Below is an example. It will walk through some of the operation of this command and flag, and give some visual examples, as well as code, to help clarify things as you proceed. This guide will go over some of the scenarios in which you may want to try to use git rebase -onto. ![]() And like any tool, you should be familiar with its operation. The command git rebase -onto is certainly not powerful enough to fix every scenario that can arise when teams start branching and merging at scale, but it is a powerful tool to have in your toolbox. But what happens when things don’t go exactly as planned? While the specific steps in this process will vary from team to team, this is, essentially, the flow when everything is going smoothly. If you use git on a regular basis, no doubt you are familiar with the standard flow of things: create and check out a new feature branch, build your feature, commit, and eventually merge it into the deployable branch. Getting Started with Git Rebase –onto for Specific Commits Getting Started with Git Rebase -onto for Specific Commits.Scenario 4: Deleting commits in the middle of a branch.Scenario 3: Move new-feature to a specific commit in main while removing the last commits in new-feature.Scenario 2: Move new-feature to a specific commit in main while removing the first commits in new-feature.Scenario 1: Move new-feature to a specific commit in main.The last thing to do is delete my tmp branches. To finish things up, I’ll just push my changes and then rebase my feature branch which will reorder my commits to match the master branch and place my feature commits as the last three commits in the log. Now in the log, I can see the history is in the correct order, just how I wanted it. Next, I merge my tmp branch into the master branch. After deleting the commits, I just save and quit my editor. This will give me the history I want with the 4th commit coming right after the last commit on the master branch. This loads the commits into my editor and from here I just delete the 3 commits that I didn’t want on my master branch. For simplicity in the commands here, we’ll just use SHA-MASTER in place of the actual SHA1 hash. ![]() I want to rebase everything back to the last commit on the master branch. I’m going to rebase this branch using interactive mode. This will give me the history that I want, but will include the 3 commits I don’t want. Now I’m going to merge the two tmp branches so that I have a history that contains all of my commits. I’ll do the same for master so that I can perform my merging and rebasing in isolation from the master branch. Next, I’ll create a temporary feature branch that I’ll use later on to bring over the commit that I want. Then I’ll checkout my feature branch and make sure it’s completely up to date with the master branch. In the current scenario, the feature branch is 4 commits ahead of the master and the branch that I want to bring over is just the most recent.įirst things first, I need to ensure my master branch is up to date. The branches I’ll be working with are master and feature. This may not be the simplest approach, but it worked for me and wanted to share. After some digging and a little trial and error, I finally figured it out. Git rocks at manipulating branches and I knew this, but I wasn’t sure how to just move one commit to the master branch. Suddenly you realize that you need to merge just the fix you made, but don’t want to merge the commits from the previous feature your working on. So, you jump right in and fix the issue and then you realize you forgot to start a new git feature branch. You’re right in the middle of developing a feature when a request comes up to fix a different completely unrelated problem. Perhaps you’ve made the same mistake I have.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |