Git - Working with dependent branches in PR based workflow

Question

I am working in a PR based workflow and here is the situation created

Two branches were created from master

1. branchA library changes, with its own ongoing PR
2. branchB app depending on library, with its own ongoing PR

Both are two different developers.

branchA changes some APIs and now branchB has to adapt to that.

branchB has to take those changes from branchA so that they test everything works properly after the API changes. I am following this approach right now.

from branchB

git fetch 
git merge branchA 

build your code and check if your changes in branchB is in sync with API changes from branchA.

Issue 1 - Next I push my changes to my PR, but now my PR has files from branchA as well along with my changes in branchB. This is happening because branchA is not yet merged to master and is still under its own PR review.

To avoid the above issue, I do the following -

I create a local copy of my changes outside the git folder, revert the merge with

git reset --hard

Now I bring those changes from local folder to git and then push it to PR.

Issue 2 - Now Because of Continuous Integration(CI) jenkins , both branchA and branchB PRs will fail the builds. To avoid this, I disable the app build on jenkins, so that branchA PR goes through the CI. And then I push branchB with app build ON.

Question -

1. How should both PRs be maintained due to dependency so that each has their own files for review.
2. Is our approach in handling CI correct. i.e disable the app till the library changes get in and then push the app
3. Or create one big PR with all the changes by merging one branch with other (after individual PRs are reviewed) with internal discussion and then push.

Answer 1

You describe a backend/frontend workflow. In my experience the backend is done first, then the frontend. That's the easiest.

Probably you describe a situation with a tight deadline. That way the backender could prepare just an API without actual business logic and provide fake data with a proper format so the frontender could start work sooner. Another solution that the fake API is emulated purely on the frontend but that's more brittle since usually a backender knows better how the API works and what data format exactly.

But if you want your GIT workflow anyway (I'll describe the work for the frontend):

• Usually backend/frontend parts are placed into separate folders.
• Checkout the backend folder while the current branch is branchB:

git checkout branchA -- src/backend

Where src/backend - your backend folder

• The backend files are added to the index so remove them from it:

git reset src/backend

(You could use git restore also)

• After work on the frontend, stage any new files in the frontend:

git add src/frontend

• Commit and push into origin/branchB

• If you don't need the backend files, clear them:

git clean src/backend

Answer 2

The OP asked in the comments whats about if the both branches are backend, so we have a situation where we work on the same files in different branches!

Hmm, it got more interesting but the solution could be even paradoxically easier:

• You are on the branchB, prepare a patch with changes from the branchA, place it maybe outside the repository:

git diff ...branchA > ../patch

• Apply the patch to the current branchB:

git apply ../patch

• Work on your feature, you could change the same files that were changed in the branchA
• Rollback changes from the branchA by reversing the patch:

git apply -R ../patch

• Now you have only your changes, commit and push

Note this is more error-prone since you could work potentially on the same code lines...

To improve DX all these scenarios could be scripted/automated, added to git and made available to all members of the team.