Created
Dec 8, 2021 6:10 AM
Department
Engineering
Category
Technology
Git
Tags
GitHubPR
Date
URL
‣
Standard PR and development Flow
- Create the feature branch (Let’s say
COM-123). Make sure to branch out frommain - Commit your changes
- Create pull request into
main. The Marvin bot will automatically create the PR for staging - Request for review on the main PR
- Wait for approval on the main PR
- Merge the staging PR
- Test changes on
staging - Merge the main PR
- Test changes on
Things to keep in mind
- When merging with
staging, if there are merge conflicts never pull fromstagingto your branch. Go tostagingand pull the changes from your feature branch. Sort the conflicts and push. stagingshould never be merged into any other branchstagingandmainshould be in sync before you can start using this flow
‣
Branch Conventions & Commits
- Use conventional commits.
- The branch name should be
UN-jira-ticket-id, for exampleUN-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, and 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 video recording 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 main branch.
