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 fromstaging
to your branch. Go tostaging
and pull the changes from your feature branch. Sort the conflicts and push. - After
staging
is verified, give a PR tomaster
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.
- 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
- @Jishnu De Sarkar
‣
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 :
- 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 :
- Seek to understand the author's perspective.
- Example :
- 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.