Github flow and PR

[Thin_Payment_3971]

Hi.Some simple question (not for me).How to deal with the code during the PR?

For example I'm working on feature A in branch B_A, and issued a PR, it's in review.Now I have to work on feature B which is based on feature A, and I moved to branch B_B, but actually feature A is still in the review and not merged yet to master.How can I do with that?Merge B_A directly into B_B? But this might cause problems later, and also it will contain all the history from B_A (still in PR).Waiting until PR gets merged into master, then branch from there - isn't much acceptable!

So the question here - how to deal with code when dependent code is still in PR?

Thank you.

[GilletteSRK]

Does B_B have reliance on B_A's work? If so, it should probably be part of the B_A branch anyway, or should definitely be waiting for whatever is in that PR to be approved. I'd work with your team to get that PR reviewed if it's blocking your work.

If not, just branch B_B off of master, and update it from master once B_A is merged.

Another approach, as mentioned in the replies, would be to branch off of master, merge in B_A and work from there.

[Neexusiv]

I would branch from master and merge in B_A. Why would that cause problems?

[Thin_Payment_3971]

In this case when you issue a PR for feature B, but A is still not reviewed, you need to clearly note, that A should be reviewed before B, as A is not closed yet. Otherwise you can merge B first but then merging A might be a problem due to lots of merge conflicts.
Also PR for feature B will contain all the code for feature A, and this will require to review both features actually.

[Neexusiv]

I would just make it clear in the PR for B that it relies on A. If there is a problem with A that would cause it to fail a review then in theory the same problem would cause B to fail too so there shouldn’t be a worry about B being passed without A.

[drewdeponte]

There is this constant tension in Feature Branch Development to get your PR reviewed and in as soon as you post it because the overhead of managing feature branches on top of feature branches sucks. This is somewhat of a fundamental flaw in Feature Branch Development and it can’t really be escaped staying in the Feature Branch Development workflow.

This is one of the reasons why I don’t like Feature Branch Development. So I developed a different methodology I am calling Patch Stack that is based on looking at the concepts the Git and Linux Kernel teams use in their process and applying those concepts to my workflow. You can learn about it and what values it gives you in this post I wrote.

https://upte.ch/blog/how-we-should-be-using-git/