The Awesome Framework - Commutatus’ definition of awesome
The Awesome Framework - Commutatus’ definition of awesome
PR Guide

PR Guide

Created
Dec 8, 2021 6:10 AM
Department
Engineering
Category
Technology
Git
Tags
Date
URL
‣

Standard PR Flow

  • Branch out from master and give a PR to staging.
  • Use conventional commits.
  • Merge with staging and if there are conflicts never pull from staging to your branch. Go to staging and pull the changes from your feature branch. Sort the conflicts and push.
  • After staging is verified, give a PR to master from your feature branch.
‣

Branch Conventions & Commits

  • Branch name should be UN-jira-ticket-id, for example: UN-325
  • If it is a parent ticket and sub tickets have the same/conflicting/dependent files, then create a branch with the parent ticket but in your commits: Each commit will represent a feature, your commit message should have scopes : (UN-323) - feat: your commit message
‣

PRs

  • Make smaller PRs w.r.t features.
  • When PRs have multiple commits, always squash and merge the respective branch.
    • image
  • Conventional commits are being followed for the commit message title, for the body one can →
    • Write the problem which was faced / what you were trying to fix. [ If this is a new feature, this is not needed. ]
    • Break down a list of changes / highlight the changes which you have made.
    • Add a Weet to go along if there are major UI level changes.
    • If at all Went is too much, you can always add screenshots to share better context.
  • Some examples of really good PRs raised by engineers :
    • @Gurkirpal Singh
      • image
    • @Jishnu De Sarkar
      • image
‣

PR Reviews

  • Usually, PRs are raised and requested for code reviews. Here, this could be used for context updates/sharing.
    • For example, let’s say you are raising a PR and you are the reviewer, here you would still request a review from all the developers in the project ( If needed, even from someone who is in the same squad, who is to later contribute here. )
    • You can decide on the threshold time for this to be open and for everyone to have context as to what are the changes. Usually, after 1 day, you can merge this and move forward.
  • For big singular features which need to be interdependent even on small features, one can raise a draft PR as well.
    • The commits will have to represent broken-down features, which reviewers can review and keep a check on.
      • Example : - Assume you are working on branch UN-100, your commits would look like this:
        • (UN-101) : Feat - Your message
        • (UN-102) : Fix - Your message
  • If the review goes beyond the time spent, you can let the reviewer know about this, after this we can decide if the feature can be moved forward with / without the review.
  • In general, whoever is requested a review would be free to →
    • Communicate which ideas you feel strongly about and those you don't.
    • Identify ways to simplify the code while still solving the problem.
      • Example :
        • image
    • If discussions turn too complex or long, please schedule a meeting to talk about this. Inform your PMs and get it on the capacity planning.
    • Offer alternative implementations if you think something better can be done.
      • Example :
        • image
    • Seek to understand the author's perspective.
      • Example :
        • image
    • Remember that you are here to provide feedback, not to be a gatekeeper.
‣

Permissions to be set up

This is to be set by the admins of the repository which involves branch protection rules for the master branch.

image