Branches
Code commits cannot and should not be directly pushed into main, main is our passing production branch.
All code is to be committed to a seperate branch relating to it's purpose. Once you are finished with that ticket/task and the branch is ready to be merged, it'll be merged into and staged on dev, from which it'll be merged into main once we are ready to move it to production.
These development branches should try to have as minimal scope as possible. For example, each feature/fix should get it's own branch and be kept within that branch until finished and merged into dev.
The purpose of this workflow is to not only protect the production environment from buggy and unfinished code, but also to allow failing code to be staged in dev along side other recently finished features it depends on.
When naming your development branches, they should be prefixed with one of the following prefixes, followed by at most three words separated by hyphens, describing the branches purpose. This isn't super strict, if you are unsure about which grouping to go with, as long as you pick one, it doesn't matter too much.
-
A branch which contains an upcoming feature implementation.
For example,/feat/user-score-graphor/feat/title-card-component. -
A branch used for quick fixes to broken code or logic that was missed before.
For example,/fix/broken-citadel-hyperlinkor/fix/zero-in-denominator. -
These are lesser used prefixes and are very situational so can often be disregarded. Style and tests in normal situations should be managed throughout the coding process and hence in their related feat/fix branches. However, if we want to add more unit tests after the code has been merged for missed cases and completeness,
/tests/...prefix may become useful.
Similarly, if we choose to do a style overhall or a rogue autoformatter went overlooked, a/style/...branch may come in handy.
