I'm using GitLab (which calls them merge requests rather than pull requests). From a couple of the comments below it seems like GitLab behaviour may be different from GitHub's.

I'm trying to get my head around how using pull requests for code reviews would work where you're developing on feature branches with a shared remote repository (rather than separate remote repositories for each developer).

Most workflows I've seen talk about pull requests from a feature branch to a shared develop branch.

The problem I see with this is when you're not sure what order the features will be released in, or even if some experimental features will be released at all. So you want to keep the feature branches "pure", without cross-contamination from other feature branches, until they're released.

To avoid mixing the changes from one feature branch with another you would never be able to merge develop into a feature branch, or rebase the feature branch on develop until the other features have been released. Pull requests would end up really messy, comparing the changes in a feature branch with a develop branch which would include changes merged from other feature branches.

The only solution I can think of would be to create a pull request between the head of a feature branch and the commit from the previous pull request on that feature branch. However, I don't think most repository hosting services like GitLab, BitBucket or GitHub support pull requests from an earlier commit to a later one on the same branch.

I feel like I'm missing something obvious here because this must be a common problem. How do other people resolve this issue of using pull requests for code reviews while keeping code in feature branches separate?

  • I'm not seeing the problem here. It's up to the code reviewer to determine the suitability of a given pull request, and the order of feature releases should not matter. Commented Nov 20, 2019 at 1:25
  • @RobertHarvey: Perhaps I didn't explain clearly. My understanding is a pull request will compare the heads of two branches, say feature-1 and develop. Say feature-2 branch was merged into develop since feature-1 was forked from develop. If I now do a pull request between feature-1 and develop then it will show all the changes in feature-1 and feature-2. However, I'd like the pull request to only include changes in feature-1. Is there any way to do this? I don't think rebasing feature-1 on develop would work because then the pull request would include all of feature-1, not just recent changes.
    – Simon Elms
    Commented Nov 20, 2019 at 3:18
  • @SimonTewsi A pull request shows all the changes that will happent to [target branch] if [source branch] is merged. So in your scenario - The pull request will show all changes that feature 1 will make to develop, regardless of changes to the develop branch since the feature 1 branch was created. If feature 1 is going to affect something feature 2 affected in develop, this will likely manifest in a merge conflict that you will need to resolve. If feature 1 & 2 are independent, then the pull request won't show anything feature 2 related.
    – Jack
    Commented Nov 20, 2019 at 14:01
  • @Jack is right. A github PR doesn't show a direct diff between the two branches. It shows a diff between the compare branch (typically the feature branch) and the merge base of the the compare branche and the base branch.
    – bdsl
    Commented Nov 20, 2019 at 14:29
  • @bdsl: I'm using GitLab. It seems to work differently, from what I can see. Our commit messages are automatically preprended with JIRA ticket numbers so I can see which branch a commit was made on from the message. The GitLab merge commit is definitely including commits from the other feature branch that was merged into develop since my branch was forked. Sounds like GitHub definitely has the advantage over GitLab on this.
    – Simon Elms
    Commented Nov 21, 2019 at 19:38

1 Answer 1


From one of your comments:

My understanding is a pull request will compare the heads of two branches, say feature-1 and develop. Say feature-2 branch was merged into develop since feature-1 was forked from develop. If I now do a pull request between feature-1 and develop then it will show all the changes in feature-1 and feature-2

I think this is just a simple misunderstanding with how Pull Requests work and what they are.

A pull request is just a request to merge one branch into another. The diff that a pull request shows you is "The difference in code between [target branch] right now, and [target branch] if you merged your branch into it".

So for you, they show you the difference between "develop" and "develop + feature-1". A pull request does not care when you created your branch, or what other branches there are, or what commits have happened on develop since starting the branch. They just show what would change if you merged your code right now.

  • This matches my understanding of what the diff would show. Perhaps I'm confused about the concept of pull requests. Everything I see online talks about them in terms of code reviews. And in a code review I'd only be interested in changes on my branch, not comparing my branch to another feature branch (which would happen with a pull request if another branch pull request were accepted and merged into develop before mine). The changes on the other branch would have already been reviewed and accepted in an earlier pull request so no need to review them twice.
    – Simon Elms
    Commented Nov 21, 2019 at 1:52
  • I just saw your comment and that of bdsl against my question. Perhaps GitLab merge requests aren't quite the same as GitHub pull requests. Because GitLab definitely included changes from a second feature branch that had been merged into develop after I'd forked my feature branch. It appeared to be a diff between the head of my feature branch and the head of develop. All our commits are automatically tagged with JIRA ticket numbers and I could see commits from the other branch in the GitLab merge request.
    – Simon Elms
    Commented Nov 21, 2019 at 2:08
  • @SimonTewsi I'm not familiar with GitLab so I'd have to defer to someone else for a better answer!
    – Jack
    Commented Nov 21, 2019 at 9:01

Your Answer

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

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