Sometimes when I am working with GitHub and seeing all those wonderful features they have, I am questioning myself “How to explain why I am using the famous pull requests (PRs)? What so brilliant about them? Why I do not commit to the master just straight away when I have the full access to do it?”.
This subject is especially important because when you have to explain to your friends, colleagues and other developers for the reasoning of using it, instead of staying speechless in front of the audience, let me provide few arguments for you.
1. Clarity of the big picture
After accumulating the experiences I received over the past years, I can note, – PRs bring the order. Simple as that. Which, in my opinion, is something that can save you time. Imagine if you put the keys on the same spot, over and over again, there will be no question where did you leave your keys, right? Same with the code. If you create PR, you will keep the history of changes you have made in small separate branches and PRs, and most of all, bring you a careful review of what has been implemented and added recently, without remembering and analyzing each commit separately.
2. It helps to review yourself
When I develop project all by myself (check out Tagliani), I use PRs despite the fact that no one will be reviewing my code except me. No matter how funny it may sound, but it has helped me to escape numerous bugs and typos many times. I have learned that it’s not only me who encountered these issues, but turns out that many developers experience the exact same thing.
Yes, I do invest more time before the code gets to the master, but it helps to avoid new bugs. On top of tests, I also have a system that allows me to avoid mistakes that we, developers, commit regularly – that is true, we are people!
3. It is self-explanatory
It gives me the opportunity to not only track the history of changes but also to change them back if I decide to go with another approach. Which thanks to GitHub, you will always be able to revert with a few clicks. You can always keep the description, comments in your PR helping to understand the idea behind the implementation, which in fact will again save time.
PRs indeed create additional complexity during your development process, you have to invest some time to create one in your project. You need to review your code before merging it, but. On top of that, it is a compliment. It is like a Yin and Yang. You spend more time on creating PRs, but it returns its favor back. It saves the time which you would waste on searching for a bug or typo in your code. If you work in a group of developers, it makes it easier to track and prevent from getting it to the master, it makes it simple to see the log of the last changes.
To some degree, it reminds the boom with test-driven development. At first, people were advocating that it’s cool, then they gradually became judgemental and were disappointed, announcing it’s crap. However, in the long run, they found out that it helps to preserve the expensive time! We just need to find the balance.
- https://en.wikipedia.org/wiki/Yin_and_yang – keep balancing between black and white.
- https://en.wikipedia.org/wiki/History_of_the_electric_vehicle – Do not commit to the
global warmingugly code.
- https://softwareengineering.stackexchange.com/a/255945 – There are multiple reasons why you would want to conduct a code review:
- https://softwareengineering.stackexchange.com/a/329832 – Pull requests provide for checks and balances, even if anyone can push to master.