Skip to content

Git Rules

Jump to bottom
Ritchelle Grace Posadas edited this page Jan 6, 2021 · 7 revisions

Git Rules

Table of Contents

Branches

  • master: Production-ready branch. Can only be merged to using the PR model. Only develop can be merged to master.
  • develop: Development branch. Can only be merged to using the PR model. Only tasks, user stories, and bug branches can be merged to develop.
  • TASK-#: Task branches. Not all tasks need code to be edited, but if you do, please name it according to the Task number.
  • US-#: Feature branches. Used to develop new features for the project. Please name it according to the User Story number.
  • BUG-#: Used for bug fixing. Please name it according to the Bug number.
  • SPIKE-#: Used for spikes. Please name it according to the Spike number.

Creating a New Branch

We will be basing all our branches from the develop branch. Why not master? Because this way, you can pull all the other features that were not yet merged to master, but exist in develop.

  1. Go to your develop branch:
git checkout develop
  1. Pull all changes that were made:
git pull
  1. Create a new branch based off of develop:
git branch BRANCH-TYPE-#/Name-of-Branch
Ex: TASK-1/Ritchelle-PR
  1. Go to your new branch and start working from there:
git checkout BRANCH-TYPE-#
Ex: git checkout TASK-1/Ritchelle-PR

Commit Messages

All commits must follow the conventional commits specification.

Conventional Commits Tooling:

Example commit message:

feat(mull-api): authenticate user before mutations or queries

secures our endpoint by checking the request header for authorization tokens before making a query or mutation

Refs #133

For further reading about good practices related to commit messages: https://chris.beams.io/posts/git-commit/

Making a PR

  1. Go to our main repo page and click on: New pull request.
  2. Select your source branch to your destination branch (unless you're doing a PR from develop to master, you're always going to merge to develop as your destination branch).
  3. Set your PR description using this template:
Example PR description:
This PR closes #4
  1. Fix any merge conflicts.
  2. At least 2 teammates have to approve the PR before it gets merged.
  3. It is up to the discretion of the PR owner if they want a re-approval (by re-requesting reviews). Ensure that the PRs can safely be merged to develop.

Before Merging

Please ensure your commits are clean before your PR is merged. Remember that you must:

  • Follow the commit template
  • Squash your commits and keep only the necessary messages
  • Only merge once the AC have been met
Clone this wiki locally