Implement Branch Naming Guidelines

[PaulGoldschmidt]

Use Case

To help identification across spezi-related projects, I would like to start a discussion around using a well-defined branch-naming guideline.

Problem

Currently, we use very different approaches to naming branches in different projects of this ecosystem. This can lead to confusion on which branch does what, especially for new devs.

Solution

Implement a system of naming-convention guidelines, e.g.:

• Feature Branches: These branches are used for developing new features. Use the prefix feature/. For instance, feature/login-system.
• Bugfix Branches: These branches are used to fix bugs in the code. Use the prefix bugfix/. For example, bugfix/header-styling.
• Hotfix Branches: These branches are made directly from the production branch to fix critical bugs in the production environment. Use the prefix hotfix/. For instance, hotfix/critical-security-issue.
• Test Branches: These branches are made to test features outside the regular development cycle.
• Release Branches: These branches are used to prepare for a new production release. They allow for last-minute dotting of i’s and crossing t’s. Use the prefix release/. For example, release/v1.0.1.
• Documentation Branches: These branches are used to write, update, or fix documentation eg. the README.md file. Use the prefix docs/. For instance, docs/api-endpoints.

Alternatives considered

We just could leave the current system (which, to my knowledge does not follow a convention) which worked fine over the last few years.

Additional context

We are not the first with a push in this direction leading to good resources (e.g. on Medium or by Microsoft)

Code of Conduct

• I agree to follow this projects's Code of Conduct and Contributing Guidelines

[PaulGoldschmidt]

It is to mention that GitHub itself provides a naming convention for branches based on issues which we could use, with the requirement of using issues everywhere.

[PSchmiedmayer]

I think that's a good idea; let's put this on the agenda for the next lab meeting. @michaelheckmann was also bringing up a similar thing as well.