Home/Development.md

@@ -2,10 +2,60 @@
 
 # Development
 
+These guidelines are there to facilitate working together on the same project. They are of course subject to change, but should lead to a more consistent development experience. 
+
 # Commit Guidelines
 
+General commit best practices apply. The main important thing is to encapsulate your commits to a **single purpose**. Do not to mix two features into one commit. Avoid mega commits, and keep them as concise and small as possible!
+
+
+## Commit Style
+
+To make the git history and especially git blame easier to read, we're tryig to follow [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/). This forces you to think about what you put into one single commit, and makes it much more readable for everyone else. 
+
+The style is as follows:
+
+```
+<type>[optional scope]: <description>
+
+[optional body]
+
+[optional footer(s)]
+```
+
+where `type` can be, but is not limited to (if you have good reasons):
+- fix
+- feat
+- docs
+- style
+- ci
+- refactor 
+- chore
+
+and `scope`:
+- interaction
+- movement
+- replication
+- pawn
+- cave
+
+These are of course also subject to change/discussion, but should give a general starting point. 
+
+
 # PR Guidelines
 
+- The same general guidelines from commits also apply to pull/merge requests. Keep them as encapsulated as possible and avoid mega PRs that nobody wants to review.
+- If you have changed uassets that are often touched, like e.g. the pawn, make small incremental changes such that merging will not be an issue if other people also work on the pawn. 
+
 # Fork / Branch Guidelines
 
+- The main repository should only contain the branches: 4.XX, 5.XX, 4.XX-dev, 5.XX-dev. Keep feature branches in your own fork to not spam the repository. 
+- Use your fork to create PRs onto the 5.XX-dev branches.
+- Never commit directly onto the main 5.XX branches. Only PRs from the dev branches will be accepted there. 
+
 # Comments / Docs
+
+We currently have no unified comment/doc style. However, the general comment guidelines apply:
+
+- Use meaningful comments, don't just state the obvious. Actually describe **why** things are like that.
+- Try and comment as much as possible, things that are obvious to you might not be obvious to somebody else!
\ No newline at end of file