Skip to main content

Contributing Guidelines

Branching​


A new branch should be created from the latest code of its destination branch from upstream. This means, at the point of branching, the local branch’s HEAD commit must be the same as the upstream branch’s HEAD commit.

Steps to create a branch:​

  • #1 to fetch all the latest code from your remote repos.
  • #2 to check out the latest code of the dev branch from upstream.
  • #3 to create a new branch named Feature/New from the latest code on the main branch

Branch naming:​

  • feat: (new feature for the user, not a new feature for build script) feat/workspace-logo
  • fix: (bug fix for the user, not a fix to a build script) fix/crash_in_home_screen
  • docs: (changes to the documentation) docs/signup_api_docs
  • style: (formatting, missing semi colons, etc; no production code change) style/removed_semi_colons
  • refactor: (refactoring production code, eg. renaming a variable) refactor/onboarding_flow
  • test: (adding missing tests, refactoring tests; no production code change) test/login_use_case
  • chore: (updating grunt tasks etc; no production code change) chore/update-webpack-plugin

Commits​


A commit should only contain what it needs. It is better to commit whenever you get something done regularly. It would help you in case you need to revert some of the commits or cherry-pick any commit to other branches as well. Don’t wait until everything is done to commit, neither to commit every line of code you write.

Commit naming​

Keep the message short but explicit.

  • Fix: - Fixed the crash in Home Screen.
  • Feature: - Implemented GameView in Play Screen.
  • Merge: - Merged latest develop to the feature branch.
  • Chore: - Increased the build number to 68 on Production.
  • Refactor: - Replaced Singleton pattern by Dependencies Injection.
  • Test: - Added unit tests for invite user use case

Pull Requests​


A pull request will not be great if the code within is not clean nor correct. Therefore, it is super important to make sure that the code you wrote is clean, well structured, optimal, and follows your organization’s conventions. Please act as a reviewer and review the changes by yourself one last time before creating the pull request. If there is anything you think could be better, make it better! It is to make sure that the code you are requesting others to review is at its best. Hence, it would help to save you as well as other reviewers a lot of time later.

Naming​

Follow the same convention as the commit naming

Pull request description​

The description helps the reviewers to better understand the motivations behind the code, achievements, and contributor’s explanations. Thus, it should answer three questions: why, what, and how. The PR will automatically come with a template, so please follow that.

  • Why? — Which tickets/issues/proposals are you working on?
  • What? — What have you done?
  • How? — What the reviewers should know?

Tags and labels​

Make sure the following fields are filled out:

  • Reviewers: who do you want to review the pull request
  • Assignee: who is responsible for the pull request
  • Labels: labels relevant to issue
  • Project: link pull request to appropriate project
  • Milestone: link pull request to appropriate project
  • Linked issue: link pull request to relevant issue

Credit: Source