Pull Requests and Gitflow

This blog was originally published by GitKraken and can be found here.

The importance of PRs in the development process.

In another post, we discussed the Gitflow model and how it helps enterprises manage releases. In this post, I will be discussing pull requests and their importance in the development process.

What Is a Pull Request?

A pull request is a development process that provides a platform for discussion and review of a completed feature. Its purpose is to notify team members that the feature has been completed and it is open for discussion or modifications. The discussion usually occurs to improve the quality of the code; it is basically a code review process.

Note:In some sites or tools, you may find the term merge request instead of pull request. Both terms mean the same thing.

What Needs to Be Done Before Creating a Pull Request?

1. Commit code in your feature branch. Note that a feature can have any number of commits.
2. Commits made in the branch only reflect changes on the local machine (i.e. your machine). So, the commits need to be pushed to the remote branch.
3. Then, you’re ready to rebase your branch. Rebasing is required if any new pull requests were merged after you had taken the feature branch.
4. After rebasing, any conflicts that arise need to be resolved, and the code needs to be pushed back to the remote branch.
5. Finally, it’s time to create a pull request.

Note: Pull requests require two distinct branches. There needs to be a difference in the code between the taken branch and source branch.

Pull Request Process

1. When creating a pull request, you add a brief overview of your feature, select the branch to which the code needs to be merged, and select the assignee who will be reviewing it.
2. Once it is created, it is open for discussion or modifications.
3. Sometimes conflicts occur after creating a pull request, and you must resolve these conflicts. Possible causes of conflicts are discussed later in this article.
4. Usually, the assigned person reviews the code, but it is not mandatory that only the assignee performs the review. Any team member can take part in the review process and give their feedback or discuss potential modifications to the code.
5. Any feedback or modifications are added in the form of comments near the code line.
6. The developer resolves comments and replies to the reviewer.
7. This process continues until all comments are resolved.
8. Once all discussions are resolved, the code is merged to the branch that was selected when the pull request was created.

Note: Pull requests can be made for any branch. Usually, they are made for the source branch. Sometimes it is okay to close a pull request without merging it. This usually occurs when a feature is dropped.

 

 

What Are Merge Conflicts and When Do They Occur in a Pull Request?

To better explain what conflicts are, consider a scenario where developer A takes a branch, feature A, from the develop branch. Another developer, developer B, takes a branch, feature B, from the develop branch.

Now both developers work on their respective feature branches. Developer A modifies a line or a block of code in the feature A branch. Developer B also modifies the same block of code that developer A has modified but in the feature B branch.

After completing their features, both developers create pull requests to the develop branch; let’s call them pull request A and pull request B. Then, a reviewer merges A. Once A is merged, a conflict arises in B because the same block of code was modified by both developers.

To resolve the conflict, developer B must rebase the feature B branch by retrieving an update from the develop branch (i.e. the source branch). After retrieving the update, developer B faces code conflicts in their local copy of the branch. Now they must resolve the conflicts and again, commit, and push code to the remote develop branch. Now the code is free of conflicts, so B can be merged by the reviewer.

To see how easy it is to resolve merge conflicts using a Git GUI client like GitKraken, watch this quick video.

Pull Requests in a Gitflow Model

• Develop Branch: A pull request is created by developers from their respective feature branches to merge code to the develop branch. Usually, it is created after features are completed. A pull request is merged to the develop branch by the reviewer. In most cases, a reviewer is a technical lead.
• Release Branch: A pull request is created by a developer from a feature or bugfix branch to merge code to the release branch. Usually, it is created during release time when a bug needs to be fixed in the release branch. The pull request is merged by the technical lead.
• Master Branch: A pull request is created by a technical lead or developer from the release branch to merge code to the master branch. Usually, it is created during release time when the code is ready for deployment. The pull request is merged by the next-level person or the technical lead who created it.
• Hotfix Branch: A pull request is created by developers from their respective bugfix branches to merge code to both the master and develop branches. Usually, a it is created to provide a critical fix in the deployed code. The pull request is merged by a reviewer. In most cases, a reviewer is a technical lead. This merge request should be reviewed with more care as it will directly merge code to the master branch.
• Note:  Although it is possible to skip pull requests and push code directly to branches, they shouldn’t be avoided as they provide better quality and stability for code.

Benefits of Pull Requests

• Use this collaborative platform to discuss potential modifications to the code.
• Improve code quality.
• Simplify the process of receiving feedback from the reviewer.
• Address feedback easily in-line near the relevant code.
• Provide better stability for the code.