Skip to main content

Git

If you are new or not majorly familiar with Git, it is HIGHLY recommended to use something like GitHub Desktop

danger

If you are ever unsure about a specific command, button or anything else git related—Please do not run it, ask for help.

Git Workflow​

When working on features, things should be split out into their own branches. This is to ensure that the main branch is always stable, and we can merge your changes in, without having to worry about breaking the main branch.

When creating branches, please follow these conventions:

  • No symbols, No spaces, all lowercase letters
  • Ensure the branch is prefixed with feature//feat/ for new features, fix/ for bug fixes, refactor/ for refactoring

Branches​

Branches are split out into their own "folders" in the repository. This is to ensure everything is organized properly, and so we know what is what.

Bug fixes are split into two different categories:

  • Bugs that have to be fixed ASAP should use the hotfix branch. The hotfix branch is created from master as needed, and will be deleted when merged.
  • Bugs that are not urgent and can wait for the next patch update should use the patch branch. You can commit straight to the patch branch, but it is recommended to create a new branch from patch and then create a pull request.
info

You may commit directly to the patch and major branches, but you MUST always create a pull request in order to commit into the staging or master branches.

Pull Requests​

Pull requests to staging and master can only be made by core maintainers (Vicky). When creating a new pull request, please ensure the title is prefixed with one of the following:

  • feature: - For features
  • fix: - For bug fixes
  • hotfix: - For hotfixes
  • refactor: - For refactoring
danger

NEVER merge your own pull request, unless told by someone else.

Commit Messages​

Commit messages should be as descriptive as possible, please do not do things like "Fixed bug" or "Increased price," instead, please explain what you did in the commit. For example, "Fixed issue where players could not withdraw money" or "Increased price of bread"—They don't have to be mega-descriptive, but just make sure it's clear in case we have to look back and find something later on.

Alongside this, please ensure you are using Conventional Commits. If you dont know what this is, here is a basic summary: Prefix all your commits with one of the following:

  • feat: - Adding new features
  • fix: - When committing a bug fix
  • refact: - When refactoring code
  • chore: - When doing a "grunt task"—Anything external users won't see

Code reviews​

Code reviews are crucial. They help ensure that the code is of high quality and that it follows the guidelines of the project. Whenever you create a pull request, someone else will review your code to make sure it is up to a good standard.

If someone has reviewed your code and given you feedback, please make sure to address it. If you have any questions about the code, please ask in the pull request comments or reach out to someone on the team.

note

Code reviewers are not here to make you feel like your code is bad, or that you are a bad programmer. Please do not take any feedback in a negative way—If you feel that a comment has been left on your code that you disagree with, explain why in the comments. We are all here to help each other and make Monolith the best it can be.

Git Flow Diagram​