Developer Workflow and Environment Prep

### Overview
In order to further streamline the process of contributing to 311-Data, a more in-depth workflow is needed. This will not only protect the most stable version of the application but also give a clear path to developers and PM's on where certain features are headed and how we can incorporate testing.

There are a lot of versions that revolve around git flow, based on the size of the team, the environment we're working through, and the consistency of code contributions, I have attached a workflow diagram for discussion.

### Action Items

- [ ] Review diagram to better understand the workflow being proposed
- [ ] Analyze whether an extra layer (develop branch) is necessary or if the release branch would substitute that.
- [ ] If workflow is adopted, create a wiki to detail out steps for reference.
- [ ] Set up proper safeguards on the `main` branch and create the necessary extra branches needed.
- [ ] Consider utilizing Git Flow CLI to help automate a lot of the rules behind the scenes
- [ ] Discuss steps on how to integrate testing into the tool using this new workflow

Workflow Diagram


Workflow Explanation

### Branches
*Main:* In the diagram we see we have a v1.0.0 (following [semantic versioning](https://www.geeksforgeeks.org/introduction-semantic-versioning/)) main branch. The idea behind this workflow is that our main branch (shown in blue) would only be updated and modified through either a fully tested and stable release build and/or an immediate hotfix needed.

*HotFix:* In tandem with the Main branch, this hotfix branch (shown in red) is rarely used but is meant to push an immediate hot fix directly to production (main branch).

*Release:* Directly below we have a release branch where all features and epics would end up (shown in orange). This is also known as a staging branch as its used for testing to ensure a bug-free and stable build before deploying the main branch.

*Release Fixes:* In tandem with the Release branch we have release fixes (shown in yellow). When testing the latest release branch, any corrections or "fixes" would deviate by creating a fix branch. This fix branch would tie directly back into the release branch. Only fixes and no new features are allowed to be on a fix branch.

*Feature:* The branches that a dev would be pushing to for features (shown in purple). Each developer would push their work into this feature branch. If the ticket they are working on is part of an epic, the feature branch serves as the epic branch and multiple developers would push their feature branches into an epic feature branch.

*Development:* These are commits local to the developer (shown in gray).

---
### Prefixes
Branches would be prefixed depending on the branch being used.

**Main:** stays as `main`
**Hotfix:** is `hotfix/`
**Release:** is `release/`
**Release Fixes:** is `fix/`
**Features:** is `feat/`