Multiple commits in pull requests

Question

We have a dev branch and a release branch. Dev branch is where all the developers check-in the code. All builds are taken from the release branch. We're using Stash (Atlassian's Enteprise Git) and wanted to incorporate code reviews using pull requests.

When someone submits a pull request, it is automatically including all the changesets from the dev branch that are not already merged into the release branch, even if they're not from the user who is submitting the request. How can the developer submit a request only for their changes and not everyone else's? Is this how it's supposed to be?

I see two workarounds -

1. Add individual branches for each developer so it picks up only their changes.
2. Add multiple approvers if the pull request has commits from multiple developers.

What is the best practice?

Solution 1

In addition to Robin's answer, the recommended approach is that each developer creates a branch for each feature that they work on, based on the development branch. Then the pull request that is created represents exactly the changes that represent a particular feature or change.

Once a pull request has been reviewed and merged into the development branch, the process you use for merging into your release branch is simplified and separate from the review process.

Stash's documentation on branching and Atlassian's git tutorials explain these concepts in more detail.

Solution 2

A pull request means a "request to pull". A pull will pull all the commits, including their dependencies - it won't cherry-pick individual commits.

So if you want to request that only your commits be pulled, and there are other people's commits in the same branch, you have to first separate your commits into a different branch.

Solution 3

Following up: if you create a fresh branch off of the dev branch, and then submit a pull request from the new branch, it will include commits from the dev branch. The solution (or at least, our solution) is to have each developer create branches off of a master branch.

Solution 4

What I currently use is this:

We have 3 branches:

• Develop
• Release
• Master

The process is as follows:

1. For each feature, we create a branch from the Master.
2. For testing, we make a Pull Request from our branch to the Develop branch.
3. When done testing, we make a Pull Request from our branch again, but to the Release Branch.
4. After every release, we make a single Pull Request from Release to Master. Note that this create additional repeated commits that eventually flow back to Develop, but no actual file changes usually occur, only commits.

Notice that in this process the Develop Branch is never merged into Release. After all, it will contain a bunch of code from other developers that isn't ready to be deployed. But my branch will contain only my code.

Just be aware of code that may impact your tests, as it may not go into the release branch at the same time. I would actually like some feedback on this architecture as well.

As an illustration, it's something like this:

• Master -> My Branch
• My Branch -> Develop
• My Branch -> Release
• Release -> Master

View more solutions