Published in


Creating a robust pull request

Photo by Annie Spratt on Unsplash
  • PRs are globally available for everyone(in the tech team), so you can read other senior engineer’s PRs, see how and why they write what line of code.
  • Your PR would also be available to everyone, make it as self-documented as possible so that it can be informative for yourself and your peers later in case of any mishaps.
  • You should be able to use your PR to help yourself(present and future) and your fellow teammates who will review your code, provide as much context of what work you did.


I am a firm believer in not creating lots of commits for a PR. Usually, the belief is to create as much commit as you can, but it makes retracing code really difficult, and git blame/git lense is not helpful to backtrack. I use git reflog to check my progress and I keep one major feature limited to one commit.
I also use git rebase -i quite a lot to manage my commits, so you can commit all you want and later squash it.
If there are more commits needed I always label the initials of the commit with the ticket number. For eg. MANGO-245 , where MANGO is the name of your team/jira board and 245 is the ticket number.

  • helps track commits in the commit history.
  • when services like datadog or trace back exceptions and errors you can pinpoint exactly which line the issue is in and in which PR did it get merged and deployed.
  • once you have a minimal commit message with information like that, it is gold to help debug where what went wrong.
  • helps hotfixes as you can cherry-pick one entire feature off of a branch if need be or remove it 🤷‍♂.

Git part

This is one of the most crucial parts, but we get so accustomed to it that we don't think about it. I want to point out my usual flow on things and then some edge cases.

$ git checkout develop  //assuming a 'main'/'develop' approach
$ git pull // to pull all the latest changes
$ git checkout -b "feature/MANGO-245-describe-the-ticket"
-- do moi werk --
$ git commit -m "MANGO-245 describe the commit"
$ git push origin head
$ git pull origin <target-branch> --rebase
$ git commit --amend --no-edit
$ git reflog
$ git rebase -i
$ git reset (--hard | --soft)

Pull request templates

I love a good PR template that makes a PR a joy to review. Apart from the fact that keeping the PR as small as possible should be a high priority, PR templates really help reviewers get a context of what sort of work has been done. Since context switching is one of the hardest tasks to do, we must assist our reviewers with enough context so that it does not add to their cognitive complexity.



Everything connected with Tech & Code. Follow to join our 1M+ monthly readers

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Abhishek Prasad

Full-stack software engineer @carsomeMY , newbie lifter, still trying to figure things out and sow things to reap