Developer Guidelines

Developer Guidelines

By Shivam Tripathi, Abhishek Kannojia, Ameen Ahmed

​Git Workflow, Git Commit Messages and Code Reviews

Git Workflow

Developer Guidelines

Part 1: ​Git Workflow

Problem Statement

• Currently, git workflows varies by teams and repositories.

• This leads to challenges in collaboration and unnecessary context switching.

• Goal is to establish a common git workflow across teams and repositories. ​

Git Workflow | Problem Statement

Developer Guidelines

Feature Branch

• Main is the stable branch.

• We checkout the feature branch from main branch.

Git Workflow | Feature Branch

Developer Guidelines

main

​feat/some-cool-feature

​git checkout -b feat/some-cool-feature

​checkout

Team Collaboration

Developer Guidelines

• Each individual developer working on the feature will create their own branch(es) from the ​main feature branch.

• After finishing their individual work, they can open a PR into the main feature branch.​

​

​

​

git checkout -b shivam/some-cool-feature

​

​

shivam/some-cool-feature

​feat/some-cool-feature

​PR

Git Workflow | Team collaboration

​feat/some-cool-feature

​Checkout

Dev launch

We checkout from the feature branch a dev branch named exp-dev/<feature_name> which can be connected to a CI/CD ​pipeline. For every launch, merge feature branch into the dev branch.

Git Workflow | Dev Launch

Developer Guidelines

​feat/some-cool-feature

​exp-dev/some-cool-feature

CI/CD Deployment

​git checkout -b exp-dev/some-cool-feature

Prod launch: Experiment

Feature branch owner will create another branch named exp/<feature_name> which will have CI/CD triggers for deployment.

Git Workflow | Prod Launch: Experiment

Developer Guidelines

​feat/some-cool-feature

​exp/some-cool-feature

CI/CD deployment

​git checkout -b exp/some-cool-feature

Prod Launch: 100%

Owner(s) of the feature feature branch will create PR against the main branch, which after review will be merged via Bitbucket/Github. Once merged, main will be merged into different running experiment branches with pre configured CI/CD triggers.

Git Workflow | Prod Launch: 100%

Developer Guidelines

​feat/some-cool-feature

main

​exp/exp-a

​exp/exp-b

​exp/main

​PR

Git WorkFlow: Summary

Git Workflow | Summary

Developer Guidelines

Part 2: Git Commit Message

Git Commit Message

Developer Guidelines

Problem Statement

• Currently, git messages are unstructured and unhelpful.​

• It is difficult to filter out which commits belonged to which features, or what exactly they changed or modified.

• It is difficult to establish what was the intent of the commit - was it a fix, a new feature, a regular chore or something else. ​

Git Commit Message | Problem Statement

Developer Guidelines

Message Style

feat(mna/india): Add support for mobile number authentication in India

​

fix(main/circular-deps): Remove circular dependency bug

​

refactor(rescore/editRunningGame): Apply strategy pattern​ when extracting marks

​

chore(​main/node): Bump node version to v16

Git Commit Message | Message Style

Developer Guidelines

Home

Open in new tab

Copy link

Part 3: Code Reviews

Code Reviews

Developer Guidelines

Problem Statement

• ​Currently PRs are an after thought, leading to fat PRs.

• Reviewing lar​ge PRs in one go is not very productive and it is not possible to do proper justice to the exercise (imagine reviewing 500+ line PR). After a point it reduces to being a formality.

• Reviewing PRs as a part of work culture also helps in knowledge transfer for both reviewer and the person who opened the PR. ​

Code Reviews | Problem Statement

Developer Guidelines

Code Reviews | Social

Developer Guidelines

Example of PRs

Developer Guidelines

https://bitbucket.org/quizizz/quizizz-workers/pull-requests/227​

Bad PR

https://bitbucket.org/quizizz/quizizz-workers/pull-requests/186​

Good PR

Code Review: Part of the process

• Instead of opening the final PR at the end of the ​development cycle, we try to break down the feature into smaller sub tasks and regularly make incremental request for reviews which is done regularly (while rest of the development continues).

• It is easier and faster to review 50-100 lines of code​.

Code Reviews | PR as a part of the process

Developer Guidelines

Code Review: Workflow

• Individual changes should ideally be merg​ed into feature branches only via Github or Bitbucket PRs.

• Changes from feature branches into main MUST be merged via Github or B​itbucket PRs.

• For individual branches, developers can use merge, squash, rebase etc as per their convenience.

Code Reviews | Reviews

Developer Guidelines

Questions?

Developer Guidelines