Github Repositories, Branches and Pull Requests

Repositories

Every independent service should have its own repository. If you as a developer do not have rights to create a repository, please contact your Team Lead.

Repositories are always private and shared with as less developers as possible.

Branches

Every repository has a main and a staging branch.

Main Branch

The main branch contains the source for the production version of the software.

Merging to the main branch is always done by creating a Pull Request from staging branch, or from a branch that is forked from the main branch.

Important: A Pull Request for merging to main should always be approved by another developer or team lead.

Staging Branch

The staging branch contains the source for the staging environment. This environment could be shared with a customer for testing. Be careful to deploy changes to this branch. If you are not sure, contact another developer or your Team Lead before merging to the staging branch.

It is important to keep the staging branch updated from main, to avoid conflicts when merging staging into main. It also prevents unexpected behavior while testing.

Changes are always applied to the staging branch via a Pull Request from a branch that was forked from the staging branch.

Pull Request

At the start of a project the Team Lead decides if the pull request needs to be approved before merging.

For merging to the Main Branch approval is always needed, unless the Team Lead decides differently.

Contact your Team Lead if you are not sure if you are allowed to merge your local branch into the staging branch.

Local testing

For local testing you could create a new branch based on the main or staging branch. Be sure to publish your local branch and commit your changes regularly to have a backup of your work on the Github servers.

Be clear in your descriptions

It is important to use clear descriptions for your (merge) commits. Be aware that it needs to be clear to other developers what your changes are about.