The best Pull Request ever in my life

If you think that Pull Requests aka Code Review is just about good code quality, you are more than welcome to read this post. I will show you what “the best Pull Request ever” can do!

What is a Pull Request?

Pull Request is a common term for reviewing someone’s else code. The name originates from one of the Git’s commands – pull – which brings changes from remote repository to your local environment. When you create Pull Request, you just request someone to pull your changes and asses the quality of your work.

Since Pull Request is popularized because of Git, you are not limited to Git. You can embrace Pull Requests mechanizm (or rather style of life) with any other repository you are using. Some of them already have built-in reviewing functionality, e.g. TFVC is equipped with Code Review (it is something like Pull Request but in TFVC world).

In further part I will use term Pull Request to describe reviewing activity, but I do not stick to any specific repository.

What is a good Pull Request?

Pull Request is not only about reviewing the code. It can be much more beneficial. I were using Git on VSTS with Pull Requests and strict branch policies and it was… great! If you have at least what VSTS gives, you can focus on daily work. It is highly probable that VSTS is not the best, but for me it is a kind of reference to compare the others with.

Pull Request policies in VSTS.
Pull Request policies in VSTS.

Sanity of common repository

Do you recall the moment when you got changes from remote repository and the build failed? Everyone gets frustrated in such situations. Sometimes it is a silly mistake such as misspelling, missing semicolon, wrong function name… You can easily fix it on your own, and the code works. Other scenario is a missing file or configuration – this time in the vast majority of the cases you are defenceless.

Regardless the source of failing build, it spoils the work and plans.

Attach automatic build as a part of each of Pull Request. What’s more, common good places to host your repository (like GitHub or VSTS) support this by design or are easy to configure. They can even mark Pull Request as rejected when build failed.

Tracking the work

Where do you track your work? Is it Jira, VSTS, Mantis, Favro, ALM, … ? Maybe Excel or mails from your boss? If it is the second group, you should think seriously about giving a try to other approach.

Regardless the work tracking system you use, it is good to attach items from that system to Pull Request.

  1. Reviewer will know the context.
  2. It is easy to discover all the source code changes linked with specific work item.

Tracking reviewers’ comments

Good Pull Request eco system should allow to attach comments to particular code structures. The discussion should also be possible. It is highly beneficial for quality when technical ping-pong starts.

Are you ready to merge?

You can also expect that good Pull Request mechanizm will check in advance whether it is possible to merge your changes with common part of repository, i.e. if there is no situation that someone else changed the part affected by you.

What is the best Pull Request ever?

There is no software tooling for that. It is about changing your mind. Stop thinking about Pull Request as it was an exam or questioning. Treat it as a…

… hands-on workshop

Both of you: the Author and the Reviewer! Give it a chance to improve your craftmanship.

If you are an Author, be opened for criticism. It is not about you, it is about the code… your code, but still – just a code. Let’s be opened for discussion. Try to catch other perspective. Learn. Develop. Try to challenge the Reviewer. Try to convince the others, but the most important, to convince yourself. Thanks to that, you are confident about your work and developed as a programmer. That was the point.

As the Reviewer, just be curious. Look around, touch, try to break. Try to offer something better. If you were asked to do review, you are probably more experienced than the Author, or at least someone sees your potential. Do not hide with that, share your knowledge, your experience. Help the others to become better programmers, but do not be surprised if you got challenged. Pull Request can help you develop your skills too.

Making clients happy

Who pays your salary? The clients. So, why don’t we make them happy? While processing Pull Request, just review requirement specification, see the context. Try to investigate what is the client’s problem, what he really needs, and keeping that in mind, look at the code again. Are the client’s needs fulfilled?


Kaizen means continuous improvement. It is business management philosophy, but you can kaizen yourself too. Just become a little better today than you were yesterday.

When you start doing “the best Pull Request ever”, you will discover, that:

  1. You are a good programmer, but can be better.
  2. Your colleague is a good programmer, but can be better.
  3. As a Team you are good, but can be better.

At that point you are just one step away from making friendly environment to work and perform where everybody is entitled to learn as well as make a mistake.


About the author

Programista lubiący ten fach. Połączenie perfekcjonisty i skauta z odrobiną eksperymentatora. Pracował dla dużych i małych, polskich i zagranicznych, prywatnych i publicznych podmiotów. Miał również przyjemność opiekować się praktykantami w jednej z poprzednich firm, jak również prowadzić ćwiczenia na Politechnice Warszawskiej, której jest dumnym absolwentem.


  1. Pingback:

Leave a Reply

Your email address will not be published. Required fields are marked *