Okay, let's imagine that you are assigned to work on 2 different features on 2 separate branches. Let's call these branches 'feature-A' and 'feature-B', and they both branch off a main branch called 'master'.
So, what we'd do is that we go to master and checkout to feature-A from there:
git checkout master
git checkout -b feature-A
After working on feature-A and you are happy with your work, you'd push your changes to the remote branch and open a pull request. Now your work is under review. Cool. Now you're ready to move on to the next task, feature-B. Likewise, you checkout to master branch and again checkout feature-B from there:
git checkout master
git checkout -b feature-B
Now you've successfully created a new branch for feature-B and you are so thrilled to work on this exciting feature... until you realized that you can't actually work on it because you need the changes that are on feature-A!
Okay, why don't just wait until feature-A is merged to master then just rebase master into feature-B? NO! You don't wait, what are you gonna say in tomorrow's stand-up?
Luckily for you, git is very versatile and there are many ways to resolve this. But a solution that I like the most is the one by AnoE on stackexchange.
The main idea is that we need the changes that we made on feature-A in order to start working on feature-B. No problem, let's just get it! Make sure you are on feature-B and rebase feature-A:
git checkout feature-B
git rebase feature-A
Or you can delete feature-B and create a new one from feature-A instead (remember, you branched from master earlier)
git branch -d feature-B
git checkout feature-A
git checkout -b feature-B
Cool, now that you have everything you need, you can work on feature-B like you normally would. And if there are any changes made on feature-A, you'd just rebase it as usual.
Now, what would happen if feature-A is finally approved and merged to master? It means that feature-B does not have to be dependent on feature-A anymore because everything that was in feature-A is now on master. So feature-B should be dependent on master now. How do you go about doing this? Ok, pull all the latest changes into your local master branch:
git checkout master
git pull origin master
Then, the moment of truth:
git checkout feature-B
git rebase --onto master feature-A feature-B
I don't know about you but when I first saw the last command, I couldn't make sense of it. What does --onto mean? Why are we mentioning all the 3 branches in one command? That's a very loaded command.
Generally, git rebase --onto is a command that you should use if you want to change the parent branch. The formula is `git branch --onto new-parent-branch current-parent-branch child-branch. This is a good article explaining the topic. Also, technically, you don't have to specify the child branch if you are already on that branch, which in our case is feature-B. The command would be as follows:
git checkout --onto master feature-A
Awesome! Your feature-B is now again based off master!
Top comments (0)