DEV Community

aishahsofea
aishahsofea

Posted on

1

Working on a branch that depends on another branch

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!

Sentry image

See why 4M developers consider Sentry, “not bad.”

Fixing code doesn’t have to be the worst part of your day. Learn how Sentry can help.

Learn more

Top comments (0)

Billboard image

The Next Generation Developer Platform

Coherence is the first Platform-as-a-Service you can control. Unlike "black-box" platforms that are opinionated about the infra you can deploy, Coherence is powered by CNC, the open-source IaC framework, which offers limitless customization.

Learn more

👋 Kindness is contagious

Please leave a ❤️ or a friendly comment on this post if you found it helpful!

Okay