Since GitHub started to grow, pull requests became very popular for open source contributions. Now, many companies are also using them to reinforce their internal code review process. We love pull requests but definitely think that there is a more efficient way to manage code reviews.
Common problems for existing Pull Requests
We noticed that many companies are trying (without success in most cases) to adapt traditional pull requests using basic conventions to fit their needs. However, there are many items that are definitely not good enough to have a super effective process:
- No way to review your pull request partially, so you don’t need to start from scratch every time a new commit is pushed
- No way to assign multiple reviewers
- No way to define mandatory and optional reviewers
- No way to define mergers
- No way to mark the pull request as “in progress” and make sure that nobody merges it by mistake
- … and many more!
You probably added to the title of some of your PRs this line (or something similar): “[not ready to merge yet]” or “[ON HOLD!! DON’T MERGE]”. Or maybe you tagged people on your PR just to make sure they were notified and ready to review it.
Or probably went further in some cases and worked with forked repositories and remote pull requests to make sure you were able to define who were the “approved” mergers (basically those who have write access to the main repository), don’t you?
The next generation of pull requests is here!
At Gitcolony, we love pull requests. We are building the next generation of pull requests, helping companies to improve their process. Now, you can review the code as it’s been written (thanks to our partial review engine), appoint a merger, select multiple people to review your work, define a due date, discuss the best solutions with your peers, make sure all your code policies are applied and much more.
Remember, with great power comes great responsibility, so use Gitcolony’s powerful pull requests wisely :)
