The benefits of a pull request workflow
Note: Article edited on the 4/12/2018
At Made Tech, we’ve experimented with a number of approaches to improve our code workflow, for example we’ve been using continuous delivery extensively to bring code closer to our users. We’ve also switched to a pull request-based (or merge request on Gitlab / Bitbucket terminology) development method for our projects and have seen many benefits from it.
If you are considering adopting this development method, here are the most compelling benefits plus some tips we want to share with you to help you implement it:
How the workflow works
The master branch becomes a production-ready branch and the only commits on master come from pull requests. Instead of everyone pushing directly to master, branches are used for every pull request. The pull request branch should be rebased often against master to make sure that branch remains unaffected by merge conflicts and breaking changes.
This pull request based deployment enables easy peer-review of the code. Instead of pushing directly through to master, everyone can comment on the changes and ask questions before merging any piece of work.
This approach has helped to solve numerous misunderstandings during our epics at Made Tech and greatly improved code quality. Feedback is easier to gather if the pull request is small, so some effort should be spent to make more concise pull requests.
Sufficient testing and better stability
Every time a commit is pushed to the branch, all the continuous integration tests are executed against the codebase. This ensures that every piece of code reaching master is usable and production ready.
The master branch, instead of being continuously broken on every commit, can now be used locally to ensure that the changes made are valid. No pull request is merged without waiting for the build to finish, which verifies that the work being done corresponds to the project standards in feature/unit tests and code quality.
The codebase has better coverage and the stability of the code is greatly improved. Having more rigorous testing helps to reduce the work upfront to fix the codebase whenever a problem occurs.
The pull requests are kept open just for a small amount of time, to get enough reviews and merged as quickly as possible. In order to support this workflow, the pull requests are kept as small as possible on purpose so they can be reviewed easily and merged quicker. Multiple pull requests can be opened if the work to be carried is too large to fit into a single one.
This workflow of staying close to master helps to reduce the amount of conflicts. Team members are encouraged to work on smaller, individual tasks that are easily committed, which also helps with this problem.
Developers, thanks to peer-review, are also increasingly aware of what is happening on the codebase, which means there is less of a need to dig into individual commits since requests for external review come quite often.
Because the master branch is now much more stable and production-ready, deployment to production can be triggered at any time without any additional effort. Frequent production deployments are contributing to reduce the friction between the users and the code being produced through quicker development cycles, and more frequent user testing.
Each developer is now responsible for the creation of the pull request and can address the peer-reviewed feedback given directly on the pull request itself. Developers have a greater sense of code ownership and responsibility since they are the only one giving the final green light to merge and deploy their code.
While this pull request based development also has some disadvantages (mainly slower merging due to the peer-review), we have witnessed a lot of positive improvements in our projects ever since we implemented it. As a result, we have rolled out this development method to all our projects within Made Tech.
We are hiring! Find out more about a career at Made Tech.