Back in the days...

My first code review during my beginner years was very simple. We didn’t have Pull Requests back then. Instead, we had something called ST – Shoulder Taps.

This is how it worked:
I would write a piece of code, walk up to a senior, “tap” them on the shoulder, and ask, “Sir, can you check if this is correct?”

It was quick, informal, and worked in small teams. With time, my projects grew, teams were distributed across the globe, Shoulder Taps were not possible anymore. Something more structured was needed.

That’s where Pull Requests came in.

What is a Pull Request?

As a developer you would write a feature or fix a bug and unit test it, write automation test cases and move to higher environment. However, before you move to the next environment, it’s always wise to get the code reviewed by someone else. This is where Pull Requests comes in.

So, A Pull Request (PR) is a way for developers to propose changes to a codebase to ensure the code changes work correctly without causing issues.

In essence, Pull Requests represents the core goals of Software Configuration Management (SCM):

Integrity – Changes are reviewed and validated before merging.
Traceability – Every change is documented with context and discussion.
Consistency – The codebase remains stable and reliable over time.

Why should someone else review ?

They may know the application better than you.
They may know the technology better than you.
They may have better ideas to design the solution.
You could’ve done certain things in a less optimized way.
You did not implement a small yet important details

Basically the Reviewer is doing you (Author) a favor and ensuring no-one stays back on a Friday night to solve a nasty high severity ticket.

How does a PR work

Instead of directly editing the main branch, developers:

Create a separate branch for the changes.
Push the changes to the remote repository.
Open a Pull Request and ask “suitable” team mate(s) to review the changes and approve accordingly.
After Approval, code changes are merged into the main codebase branch.

Yes, the process does slow down things (and some developers may hate it) but gives the teams Great Control so that production will not break easily!

Being Consistent with PRs

I deeply value Consistency. Consistency becomes even more important while developing, since the code belongs to everyone in the tech team. And when it comes to reviewing code, the same principle applies. Consistency makes reviews faster, reduces misunderstandings, and keeps the entire team aligned.

Now imagine This:

There’s no defined process for how to raise a PR or what information should be included.

What will happen is:

Some people are over-communicative, write an essay for a 2-line change (That would be me).
Some would just say ”Approve this PR” with zero context.
Some write tests and many don’t bother.
A few leave code with warnings and errors to meet the deadline.
And some even leave behind spelling mistakes (I hate spelling mistakes!).

For an Engineering Manager, this is no worse nightmare!

That’s exactly why Pull Request templates matter. They bring structure and consistency to the review process, ensuring every PR communicates the right information before it even reaches the reviewer.

Pull Request Template

Instead, Why not set clear expectations for what a PR should contain, throw in a checklists and provide placeholders for screenshots.

Here is why A PR Template is Important:

Consistency: Every PR follows the same structure.
Clarity: Reviewers get all the context they need upfront.
Efficiency: Less back-and-forth; faster approvals.
Quality: Built-in checklists prevent missed steps (like tests or documentation).

A PR Template creates a uniform way for collaboration, making reviews faster, cleaner, and far less chaotic.

How to create a Pull Request Template

Its very Easy. You need to create a markdown file inside a folder called .github inside the root of your your project.

The .git folder and .github folder are on the same level. Do note that, the two folders are not really related and I added it here so that you understand where this .github folder lives inside the codebase.

And Don’t forget to push the markdown file.

.github/pull_request_template.md

Content of the template

This depends on project to project, technology and few more things but in general I would like to have the template as below.

## Summary of Changes.

## Type of Change
- [ ] Feature
- [ ] Bug fix
- [ ] Optimization
- [ ] Documentation
- [ ] Tech Debt

## Implementation Details
What was done?


## Special Instructions if any



## Testing
Steps for reviewers to verify:
1. 
2. 

## Checklist
- [ ] My Code follows project guidelines
- [ ] I have added Tests for my changes.
- [ ] My code does not generate new warnings/errors
- [ ] I have done a self review of the code.

## Screenshots or Videos

Best Practices for Pull Request Templates

Keep the template short and clear.
Use checklists, They are super powerful.
Evolve the templates when needed.

Personally, I feel A Pull Request Template is one of those tiny one time investments with huge returns. It saves time, prevents misunderstandings, and improves overall code quality and keep developers happy.

Try this with your team today and let me know how it went.

Let's Connect

Hi, I’m Sandeep Gokhale, and I'm passionate about building high-performing teams at my company, Techvito and I write about Technology, People, Processes and some more fun stuff.

One of my life’s missions is to do whatever it takes to build world-class products and deliver exceptional client outcomes.

In case you're looking out for a technology partner to accelerate your business goals with clarity, speed, and quality & security, my team and I are here and more than ready to help you make it happen.

Feel free to connect with me on LinkedIn and Twitter.

Until Next time!

How to Create an Effective Pull Request Template