/
Git Workflow

Git Workflow

Owned by Tim Zhang
Last updated: Feb 04, 2022
2 min read

Main Branches:

The table below shows the main branches in our project

Branch

Purpose

Branch

Purpose

master

A stable development branch containing all our most recent features.

production

Contains our stable release. Anything pushed/merged to this branch will be deployable by a click of a button on Rancher.

Note: no development ever occurs on this branch.

Conventions:

Branch Naming:

Use your initials followed by a forward slash / and a very concise description of the goal of the branch.

Eg. when John Shepherd wants to restyle our navbar, he’ll create a new branch with name JS/restyle-navbar.

 

Commit Message:

Describe your changes in imperative mood, e.g. "make xyzzy do frotz" instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy to do frotz", as if you are giving orders to the codebase to change its behavior.

This is recommended by Git’s documentation, so avoid the temptation to write messages in past tense.

There’s no need to strictly follow conventions, but it helps to streamline code reviews!

Process

  1. Make a branch for every feature you work on.

  2. While working on the branch, make sure you pull often from master to avoid massive merge conflicts.

  3. When your feature is ready to deploy, open a pull request and assign a reviewer.

  4. Move your ticket to ‘READY FOR REVIEW’ under the Jira board.

  5. Once you’ve received feedback, make any edits to your code that you need and notify your reviewer for approval/more feedback.

  6. Once everything is approved, merge in the pull request. The feature is then ready to deploy.

Try to keep your pull requests as small as possible. It’ll take much longer for your code to be reviewed otherwise.

You don’t have to apply all feedback if you don’t think it’s applicable. Reply to your reviewer's comment to justify why you didn’t make a change.

Reviewing code

As a reviewer, you should be on the lookout for…

  1. Any style issues that can’t be caught by the linter. These include but are not limited to:

    1. Massive files.

    2. Need for structural changes (moving things to different directories).

    3. Copy-pasta code.

    4. Comments in weird places (e.g. inline comments, comments within conditional statements)

    5. Lack of documentation.

    6. Code that looks very C-like and doesn’t take advantage of JavaScript shortcuts.

    7. Typos in comments/variable names misspelled.

    8. The occasional weird indentation.

  2. Code that looks buggy or too complicated or error prone. Make a comment about possible fixes. If that’s not possible, ask the reviewee to fix it or justify why they wrote their code that way.

Nitpicking is okay, but also be nice! If possible, try to suggest improvements.

Make Sure You…

  • Know the essential git commands:

    git add git commit git status git branch git checkout git merge git pull git push

  • Know what pull requests are, and how to make them.

  • Know about the code review process on GitHub whenever you want to make a pull request to master.

    • You’ll need to experience this at least once to know how it works in this project!

 

 

Related content

UNSW CSESoc