We are using GitHub as our source code repository along with Visual Studio. We are going to start to use the GitFlow branching model, so a new feature request will be branched off and worked on in isolation. This feature could be worked on by a single developer or multiple developers, e.g. UI, API.

However, we also want to introduce code reviews. I believe this is carried out by using pull requests. I can understand and see how this would work if a single person is working on a feature branch - check in, pull request, developer reviews and responds.

However, if multiple developers are working on a feature branch, how are pull requests and code reviews achieved? Any examples of processes in this scenario?

Would each developer working on a branch create their own child branch from the feature?

  • It really depends on granularity - the first step would be avoiding excessively large features in the first place, but also GitFlow includes a development branch for integration, so reviews would happen when merging into develop. It sounds like you might just end up with a whole bunch of unnecessary extra reviews for unfinished features(feature branches should be running against CI with all static analysis and tests run for every push so this should catch most issues). Individual developers could choose to branch from the feature if that suits them, but I wouldn't add reviews at this level Dec 5, 2021 at 10:36
  • 3
    Another thing to consider - if multiple developers are working in the same code, then reviews are effectively happening already on a passive, ongoing basis after they pull down the latest changes, while they're working in that same area. Dec 5, 2021 at 10:46
  • Code reviews are a human procedure and require human conventions. Look for example at what is done for GCC Dec 8, 2021 at 17:09

2 Answers 2


I would suggest that the feature branch is in turn again branched by each developer so that they work on their own copy and pull in from the feature branch on a regular basis at their own convenience (as opposed to the latest commit breaking their own code when doing the necessary pulls)

Then you can review just their work on their own branch before merging into the feature branch.

  • 1
    Three downvoters! Feel free to elaborate on why, so it can be clarified why this is not a good idea for OP... Dec 7, 2021 at 19:09

We also work with git-flow, multiple people to a feature and reviews. What works for us is

  • 1 branch for the entire feature (no sub-branches off it for individual developers)
  • The people working on the feature divide the work among themselves in whatever way suits them
  • The people working on the feature communicate regularly with each other
  • Once everyone thinks the feature is ready to be merged to develop, one person creates a pull request and invites people to review it
  • The reviewers publicly make their comments in the reviewing tool (we use Atlassian Bitbucket for that)
  • All people working on the feature keep an eye on the pull request to see what review comments are being given and to respond to them
  • When the reviewers are satisfied the code can be merged, then someone performs the actual merge. Usually it is the person who opened the pull request, but it can be anyone.

A lot in this workflow depends on communication. I believe that is key in all successful workflows where multiple people work on a feature.

  • What would be some disadvantages of creating sub-branches for each developer?
    – matkv
    Dec 5, 2021 at 13:53
  • @matkv, one disadvantage would be that it is harder to get each other 's work-in-progress. For example if one is writing the implementation and another the unit tests. Dec 5, 2021 at 16:34
  • 1
    @BartvanIngenSchenau It is not that much harder. All you need to do is to merge in the branch. As opposed to it coming in without notice. Dec 7, 2021 at 19:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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