Git flow and code reviews - nimbletank/nimbletank-coding-standards GitHub Wiki

Nimbletank use of git flow, along with our use of pull requests ensures quality code at all times.

Code reviews and pull requests

All development code should be done on feature branches (see git flow diagram below) and the only way it can be merged into develop branch is through a pull request (PR).

How to make a pull request

  • Push your local feature branch code the remote repo
  • Create a new PR on Bitbucket
  • Add any relevant reviewers; at least two people will be needed to approve it
  • Check which branch the feature branch will be merged in to. In most cases you will be merging into the develop branch.

Anatomy of a good pull request (PR)

  • Clear, plain-speaking title
  • Clear description - this should give an overview of what was done in the feature, and should include the JIRA ticket number
  • Confirmation that the PR was tested on the various devices and browsers that the project

Who merges PRs?

The project maintainer merges the feature into the official repository and closes the pull request

Code Reviews

How to review code properly

  • Foster a positive code review culture. Reviews should not be about placing blame but ensuring consistency and promoting quality
  • Leave comments inline so the context is clear
  • The advice from this post is extremely useful for code reviews

Git flow

The below diagram illustrates Nimbletank's git flow process for all projects, regardless of type (e.g. native app, website etc)

Git branch naming strategy

  • master (release)
  • develop (ongoing dev)
  • feature/MCM2020-459_login-ui (pulled from develop, merged back into develop)
  • fix/MCM200-43_something-broke (pulled from develop, merged back into develop)
  • hotfix/something-broke (pulled from master, merged back into master)

Nimbletank's Git flow diagram

Resources