Git Workflow

tip

Ensuring our git branches, commits, and pull requests are standardised will improve efficiency with development, and have a more streamlined CI/CD pipeline.

Please follow the below standards when using git:

General standards:

• Do not push to main. If the dev branch is going to be merged with main, a pull request is to be created and reviewed by all devs before the branch is merged with main.
• All development is to be a branch of the dev branch. Once the development is completed, a pull request is to be created and merged in to dev branch.
• Any code changes are to be done in a branch off dev, and merged back in to dev once completed via a pull request. Limit pushes to dev to extremely minor changes (e.g. single CSS class added to component)

Branching

tip

Whenever a change to code has to occur, branch off the dev branch, make changes, and pull request to add the changes back to the dev branch.

Naming standard for creating branches:

• Include a branch prefix, the scope short description of the branch. e.g. for a branch creating a new feature (login page), name branch “feature(login-page) create new login page”.
• Use the below standard prefixes:

type	description
feat	A new feature
fix	A bug fix
docs	Documentation changes only
style	Changes that do not affect the meaning of the code (white-space, formatting, semi-colons)
refactor	A code change that neither fixes a bug or adds a feature
perf	A code change the improves performance
test	Add missing tests
chore	Changes to the build process or auxiliary tools and libraries

Committing and Pushing

tip

Descriptive commits are important for other developers in the team to understand exactly what changes have been made to the code.

Standards for commits:

• Whenever you commit to git, ensure your commit message includes the type, scope a short but succinct description of exactly what changes have occurred. e.g. for a commit that has added a button to a login page, commit message could be “Login page button added to login form”.

tip

Use Commitzen globally to standardise your commit messages with an interactive CLI tool.

Commitzen on GitHub

Pull Requests

tip

Pull requests are important for the code that you have written to be check by somebody else in the team, but also for other team members to be on-top of what code changes have occurred.

Standards for pull requests:

• Include in the initial comment, an outline of exactly what changes have occurred on the branch in a short and succinct summary.
• If needed, include a link to the Notion card to give more detail on the changes that have occurred.
• If the branch includes a significant style change, or you want another team member to review the design of the branch, include “Design review required” followed by a link to the Figma which includes the design that you have based the branch off.

Reviewing pull requests:

• When reviewing a pull request, ensure you carefully check the code changes that have occurred. If required, add a comment to a specific line of code and explain what the issue with the code is at that line.
• If a design review has been included, ensure you carefully check the Figma design against the final webpage. If there are any issues with the design, include this in a comment on the pull request.
• Once the pull request has been reviewed, and any issues raised have been closed, approve the pull request.

Merging pull requests:

• Once a pull request has been approved, the owner of the branch is to merge the branch with the dev branch.
• Once the branch has been successfully merged, the old branch is to be deleted.