Update Contributing.md

HJfod · Oct 14, 2023 · 9fd7115 · 9fd7115
1 parent 744d61a
commit 9fd7115
Showing 1 changed file with 5 additions and 3 deletions.
diff --git a/docs/Contributing.md b/docs/Contributing.md
@@ -13,7 +13,7 @@ If you'd like to join the dev team, the easiest way is to just express your inte
 
 BetterEdit 5 is developed using [Geode](https://geode-sdk.org), making it a required installation for all contributors. Aside from the basic Geode toolkit, BE currently doesn't require any additional special tools, though this may change in the future.
 
-BetterEdit is split into two mods: BetterEdit and EditorAPI. The former is the mod you all know; it adds all the QoL features like Start Pos tools and better color selection menu. The latter is a general API mod that introduces a bunch of endpoints for adding stuff to the editor, such as new build tabs. This is where any features that other mods could depend on should go; BetterEdit should just be about using EditorAPI & other APIs to contribute its features.
+BetterEdit is split into two mods: **BetterEdit** and **EditorAPI**. The former is the mod you all know; it adds all the QoL features like Start Pos tools and better color selection menu. The latter is a general API mod that introduces a bunch of endpoints for adding stuff to the editor, such as new build tabs. This is where any features that other mods could depend on should go; BetterEdit should just be about using EditorAPI & other APIs to contribute its features.
 
 An overview of the BE codebase's structure:
 
@@ -35,9 +35,11 @@ However, some features may be logically distinct and not extractable into a shar
 
 ## Branches
 
-The development of BetterEdit is handled using branches, and every developer should use their own branches. In fact, **pushing directly to the `main` branch is disallowed**, and may only be done so through PRs that have succesfully passed [the build action](https://github.com/HJfod/BetterEdit/actions/workflows/build.yml). This is to ensure that the `main` branch always consists of code that has been tested and that succesfully builds - `main` should not be a development branch.
+The development of BetterEdit is handled using multiple development branches. In fact, **pushing directly to the `main` branch is disallowed**, and may only be done so through PRs that have succesfully passed [the build action](https://github.com/HJfod/BetterEdit/actions/workflows/build.yml). This is to ensure that the `main` branch always consists of code that has been tested and that succesfully builds - `main` should not be a development branch.
 
-**Branches should mainly be made per-feature or per-contribution**, and only contain changes relevant for that one contribution. For example, this document was developed on an `updated-docs` branch, which only added new Markdown files under `docs`.
+**Branches should mainly be made per-feature or per-contribution**, and only contain changes relevant for that one contribution. For example, this document was developed on an `updated-docs` branch, which only added new Markdown files under `docs`. **All development branches should be forks of `main`**, unless there is a good reason for a branch to be a fork of another development branch.
+
+You should generally avoid making branches with a bunch of unrelated features like [HJfod's branch](https://github.com/HJfod/BetterEdit/tree/__SECRET_HJFOD_BRANCH_DO_NOT_TOUCH_OR_YOU_WILL_BE_FIRED), although doing so can be fine if you're just trying stuff out, or if you're HJfod and are working on super secret and super awesome stuff.
 
 ## What features should I add?