Branch and PR standards - decentraland/unity-explorer GitHub Wiki

Branches

The unity explorer codebase is held in 2 main branches:

  • dev: where all the branches are merged
  • main: the branch used to create new releases

When working on a bug or a new functionality, it's important that the code is committed in a separated branch based on the dev branch.

We are using the following naming convention:

  • feat/... - for branches about new functionalities
  • fix/... - for branches about bugfixing
  • chore/... - for chores like as code cleanup, minor tweaks
  • opti/... - for optimization related things

It is allowed to create feature-related sublevel there - feat/analytics/..., fix/sdk-scene/...

Pull requests

In order to merge the changes made in a branch, a pull request has to be created in Git Hub.

The PR name can mimic the branch name with the following LOWERCASE convention:

  • feat:
  • fix:
  • chore:
  • opti:

If the PR solves an issue it is important that the description contains the following text: Fix #IssueNumber So that the issue will be automatically linked with the PR and closed once the PR is merged.

As the PR template will suggest, the description needs to contain a few important sections:

  • A generic description of what the PR achieves
  • A technical description to help guide technical reviews
  • A step by step guide to help QA test the results

To merge the PR multiple steps have to be completed:

  • The PR needs to be reviewed and approved by QA
  • The PR needs to be reviewed and approved by developers
  • The build and tests need to be succesfull

Once all the steps have been reached the PR can be merged with the 'squash and merge' button

Commits

When adding commits to your branch there is no need of following any guidelines. Since approved PR will be squashed before merging into dev (see below), it is allowed to use any amount of commits. It is suggested to commit often (considering it as saving points of your progress)

Merging approved PR into dev

In this case squash merge option should be used. Also, it is important to provide a descriptive message, following the standard:

  • a self explanatory title
  • a list of all changes in the description
  • test steps

This will generally be auto generated by git hub when clicking on squash and merge, but it is better to copy main part of your description including test steps