Git Commit and Workflow Changes

[MapleWheels]

Tagging: @Torca2001 @Mannatwo @PeasantFoundry

In an effort to expand and standardize the development process. I am proposing we implement something akin to the Champion System, this system is designed to create accountability and flexibility in a volunteer work environment while also making sure we're on the same page:

Copy-pasta of my Discord message:

The process I would recommend based on my experience is;

Git Structure:

Git Flow

This git should have 3 base branches:

• dev: This branch is where all new features, general bugfixes and changes are made/PR'd to.
• testing: This branch acts as the playtest version of the branch. Any balance changes and hotfixes are made here and are rebased into dev. This allows us to create a stable version working off of this branch.
• main (aka release): This branch exists as what will be released on Steam Workshop/Github Releases (if we ever do them).

Git Repo Authority/Process

• Author: @PeasantFoundry (Hadrada).
  -- Full permissions, can do anything.
• Developers: Everyone else accepted by @PeasantFoundry as a primary dev member.
  -- Allowed to accept PRs to the dev branch only. This will allow fast iterations in development without requiring large rebase and merge from PR contributors due to delays in accepting PRs (PR becomes stale).

As Hadrada is busy, it would become his job to instead make sure that the dev branch is in a state where he feel's that he's happy with it before merging it with testing (creative control), while still allowing other developers to work on the mod actively.

Champion/Development System:

Part 1 : Discovery & Discussion

1. Dev (or anyone) opens a feature or issue discussion.
2. After a back and forth, more feature discussions are created if necessary based on separation of concerns, feature creep and scope limitations.
   -- Adding to the above, we try to isolate this feature's codebase changes as much as reasonable.
3. A code-base change is quantified for this so we don't have multiple people rewriting the same code (dev conflict).
4. If necessary, create an order that features need to be completed in.
5. Mark the features as "awaiting champion".

Part 2 : Work Assignment and Submission

1. Champion takes up a feature or issue (can be a Developer or community contributor).
2. Champion makes a PR.
3. PR gets checked by a Developer and rejected or accepted.
   3b. If a Champion wishes to abandon, they have to make a post stating why and the branch the development was occurring on. This will allow the feature to be marked as open so another Champion can volunteer to complete it and work off of the existing branch.

Part 3 : Mod Release Planning

1. Hadrada defines a target date for a Release Candidate from the dev branch (usually coincides with a few days before a Luatrama or Barotrauma update).
2. dev branch completes work on accepted PRs as necessary.
3. dev gets pulled into testing by @PeasantFoundry .
4. testing gets more bug fix testing and balance changes.
   -- Changes are pulled into dev (merge/rebase) by any Developer.
   -- All changes in testing are either made or pre-approved by @PeasantFoundry .
   -- QC branch changes (bugfix, gameplay balancing, etc.). also follow the Champions+System but is much looser (it's easier for the person familiar with the code/mechanic to help fix it).
5. Once QC branch passes and @PeasantFoundry is happy with it, Hadrada pushes it to master and makes a proper release for the Steam Workshop.

This also lets you separate unit tests, CI/CD by branch. dev will only get unit testing, testing will also have full integration tests and end-to-end tests.

Tell me what you guys think.

[MapleWheels]

Also, for context on write-access: https://stackoverflow.com/questions/38864405/how-to-restrict-access-to-the-master-branch-in-git