2

Two developers (front-end and back-end) are working on one User Story, while the front-end is dependent on the work of the back-end. What is the best way to handle this dependency regarding the branches:

  1. The back-end creates a branch, works on that, and the frontend continue to work on the same branch.

  2. The front-end creates a second branch based on the first feature branch.

We squash our commits when we merge to main, so with the second possibility we would need to cherry-pick the changes and could not easily rebase the second branch onto main, due to the difference in the commit history.

Should a front-end and back-end developer share a branch and create a shared PR?

Does it need to be reviewed by 2 people then, one front-end and one back-end?

Improve this question

2 Answers 2

Reset to default
5

I would prefer the approach where all the work necessary for a particular story is done in the same branch. This approach often reduces some burden of integration, and the work would only need to be synchronized with changes in an upstream development or integration branch for other changes without the need for sharing across feature branches. You would have access to the correct and current state of backend, frontend, integration and end-to-end automated tests.

However, no branching strategy can replace effective communication and collaboration between developers. Effective communication between the front-end and back-end developers would help make sure that the work is well integrated. I would even push for moving toward pair programming where the front-end and back-end developers are working together, at the same time, on the changes, and communicating about what they are finding. Handoffs introduce waste. Finding issues in integration and having to wait is a form of a handoff, as well. Eliminate as many handoffs as possible, with the extreme end having cross-trained developers who can work on all necessary aspects of a story. The use of pair and mob programming strategies can reduce handoffs and help cross-train developers.

The creation of a pull request and who needs to review it depends on your process requirements. You may be able to fully automate your pull request, especially if you are using pair and/or mob programming. You would need to define what the objectives of the pull request are in order to determine if one is needed and who, if anyone, should be human reviewers.

Improve this answer
3
  • 2
    +1 You cannot use a branching strategy in any VCS as a substitute for team communication and collaboration.
    – Greg Burghardt
    Oct 7, 2022 at 10:45
  • 1
    @GregBurghardt Absolutely. I'm going to even make that sentence stronger than it is now.
    – Thomas Owens ♦
    Oct 7, 2022 at 10:57
  • Boldface text, preferably. It's funny. It feels like most of my answers to git questions basically say "this isn't a version control problem." People either need to use a more specialized tool or talk to someone. This question falls into the "talk to someone" category.
    – Greg Burghardt
    Oct 7, 2022 at 11:18
2

Should a front-end and back-end developer share a branch and create a shared PR?

They could share a branch. I think that break the work in two branches add unnecessary complexity.

It's better to have both developers synchronized with the work of each other as much as possible. You can do that with a culture where the developers commit frequently and without break the build of the branch they are working with. So, every change that could affect each other will be identified and resolved faster.

Does it need to be reviewed by 2 people then, one front-end and one back-end?

I assume that the Team has a good communication. So, if necessary, the members of the team can ask for a backend and frontend developers do the review.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.