Git Workflow

Branches

• master: This is our production code. It should contain a working version at all times.

• develop: This branch contains the current status for the development team. Here you can check whether the features you developed on different branches work together nicely. It may fail at certain times, but should be fixed as soon as possible (especially never merge another feature onto a failing dev branch).

• change: For each incremental change open a new branch for yourself (or you and your pair-programming partner) where you can develop in peace. These branches may fail or even be deleted all together. Name them according to the standards (see below).

For each change branch you should immediately open a merge request onto the develop branch (and mark it as WIP), so the CI will run after every change and you get immediate feedback.

Branch Names

Please start a new branch for each change and name it accordingly to it's category:

• feature/title
• refactor/title
• fix/title

Branches that are still Work in Progress need to be indicated as such (WIP).

Reviews

There needs to be at least one review from a team member who has not worked on the branch before merging into develop! The workflow is as follows:

When a team has finished the work on a branch, they can remove the WIP Flag and assign a different Team member as reviewer.

The reviewer can now look through the code and make sure to understand all the changes. Annotate any questions, change requests, etc. as review comments in Github. (Don't forget to send the review, so the team will be notified about the finished review!)

Now the team can implement or annotate the requested changes.

Once everything is fine, the reviewer can approve the Merge Request.

An approved Merge Request can be merged into the develop branch.