Working on a branch with a dependence on another branch that is being reviewed

Question

How does git help deal with the scenario below:

I have a task broken down into 2 parts: backend task and frontend task. I make a pull request to merge the backend changes and wait for it to be merged (and address feedback). While waiting, I can't really work on the frontend changes because it depends on backend changes and those are not available on the master branch yet.

What is the best way to pull in changes to frontend changes branch from the backend changes branch while it is still being reviewed?

Answer 1

Hold on, skip merging

For this approach, you do not want to merge your feature_a into feature_b repeatedly.

Rebasing has been mentioned in other answers, but only for rebasing things onto master. What you want to do in your case is:

• Start your feature_b from feature_a, i.e.:

  git checkout feature_a
  git checkout -b feature_b
  

• Whenever feature_a changes while it is waiting to get merged into master, you rebase feature_b on it:

  ... commit something onto feature_a ...
  git checkout feature_b
  git rebase feature_a
  

• Finally, as soon as feature_a has been merged into master, you simply get the new master and rebase feature_aonto it a last time:

  git checkout master
  git pull origin master
  git checkout feature_b
  git rebase --onto master feature_a feature_b
  

  This final rebase will graft all commits that are dangling from the feature_acommit (which is now irrelevant as it has been merged into master) right onto master. Your feature_b is now a simple, standard branch going right from master.

EDIT: inspired from the comments, a little heads up: if you need to make some change which affects both features, then be sure to make it in feature_a (and then rebase as shown). Do not make it in two different commits in both branches, even if may be tempting; as feature_a is part of the history of feature_b, having the single change in two different commits will be semantically wrong and possibly lead to conflicts or "resurrections" of unwanted code, later.

Answer 2

I have this problem too sometimes. Git is very flexible. Here's one way you can do it.

Your first branch featureA is up for review.

Your second branch featureB is in development and depends on the code in the featureA branch.

Merge the featureA branch into the featureB branch.

If you make changes to the featureA branch then you should merge the featureA branch into the featureB branch again to incorporate the changes.

You should also make sure to merge featureA into the main trunk first, otherwise when you merge featureB into the main trunk you will inadvertently also merge featureA. Once featureA is merged into the main trunk you can get rid of the featureA branch as featureB only depends on the main trunk now.

I prefer it when my feature branches do not depend on each other but sometimes they do and you have to roll with it.

Answer 3

You already have a branch on which your every feature branch depends, and which keeps changing. It's called master.

The typical way for a feature branch to stay in sync with master is to stay on top of it. When master changes, you normally git fetch origin master:master && git rebase master in your branch's working directory.

You can do the very same thing with another feature branch: keep fetching it and rebasing on top of it.

If, for some reason, you'll need to move your changes to a different branch, you can cherry-pick your commits, which are never mixed with other branch's commits.

Answer 4

In this case where the frontend task has a critical dependency on the backend code, and you want to start work on the frontend before the backend is finalised and accepted on master, I would simply start the frontend task as a feature branch coming off from the backend branch, rather than branching the frontend on master.

A feature branch that lives long enough needs to merge in changes from master occaisionally (to make sure you to reconcile any merge or semantic conflicts as part of dev work on the feature branch, rather than as part of the "review, qa, merge-to-master" process). So you do that on your front end branch, and when the backend work has been accepted to master, you'll get any minor changes that were made to the backend as part of its review/acceptance automatically, by the same route you'd get any other code changes on master.

If it turns out the backend branch needs a lot more work and it continues to change over a period of time before being merged to master (say if major problems are found during review), then you you'd probably want to do periodic merges directly from the backend branch into the frontend branch (so you don't keep basing all of your frontend work on obsolete backend code). This is easy if you're the only developer doing both features (since you know if you yourself make any major changes), but even if both features end up being worked on in parallel by different devs it should be fine; you just have to stay in communication (which you would need to anyway, if you're working on tasks in parallel where one has a critical dependency on the other).

If it turns out that the whole backend branch needs to be abandoned and will never be merged (it sounds like this would be a pretty major deal that would rarely happen), then you either cherry-pick your commits to a new branch coming off master without the backend work, or you apply reverse commits that remove all the backend code to the frontend branch. But as I can see it would be more likely to pause the frontend work until you'd figure out what was going to replace the backend you're throwing out, and then decide what to do.

Answer 5

I do not see the problem here.

You already have this every time with your master branch, which keeps changing while features are developed and then merged.

So, in your concrete example, you first create the feature_xxx_backend branch and develop the backend changes. When this is done, the branch is up to review and will be merged into master once the review is complete.

So, simply start another branch, feature_yyy_frontend. You will probably want to branch directly from feature_xxx_backend, so that you have those changes already in your branc. then simply develop the frontend feature asif the branch were master.

When the feature_xxx_backend branch changes, e.g. because there are things that come up during review that need to be adressed, simply do these changes and merge them into the feature_yyy_frontend branch. Then continue on the frontend branch.

Once the review of the backend branch is completed, it gets merged into master. At this point, it would be wise to rebase the feature_yyy_frontend branch onto master, so that the reviewers only need to review the new changes that this branch contributes to master, and not need to re-review the changes made for the backend (which have already been approved).

This can also be done when you have two, three or more dependent branches. If you have two feature branches you depend on, simple make a derived branch that has both feature merged in. Branch from there, develop the third feature, merge both feature branches along the way when each of those change. When both features are done and get merged into either the derived branch, rebase onto that, or if they get merged into master, rebase onto master.

Rebasing (as suggested above) is really powerful and helps keeping a clean log of the changes, making reviews much easier.

Answer 6

As Polygnome mentioned, you can actually merge your frontend branch with your backend branch instead of the masters. Even with the current branch setup you have now, you can simply do:

git checkout frontend
git merge backend

or simply

git merge backend frontend

Keep in mind though that if backend changes are not accepted and more work is needed, you'll have to merge updates from the backend into the frontend to avoid conflicts. Once the changes are accepted into the master, you can rebase your frontend on the master to get rid of the backend merge commits.

Technically you could also do everything with rebase, but that will mess up the commit history of your frontend branch. Where I'm coming from, this is considered bad practice. YMMV

Answer 7

Most answers in here correctly describe the process of merging the changes from the second branch to the first, but they do not address how to minimize the amount of conflicts that you may need to resolve.

Whenever you have two sets of big changes that you want to review individually (like featureA and featureB), create a PR that's NOT meant to be merged, but to gather early feedback on a PoC of featureA.

People will be able to review it quickly (it's just a PoC), and the objective is to validate the general design or approach.

Then, you can keep working on feature A, create a pull request for it and branch and work on feature B.

The big difference is that now you can expect featureA to not change radically: the design and approach were already validated. The code review and required changes may be subtle and local rather than a "woops, you need a different approach". This will minimize the amount of work that you need to do to later on merge featureB on featureA's code, regardless of the method you chose.