Update git flow convention in documentation (#527)

* Adding contributing/releases documentation to match the new git flow we'll be adopting

* Fixing formating

* Formatting

* Fixing some informational issues

* Fix

* Update CONTRIBUTING.md

fixes links and edits

Co-authored-by: mitchelbaker-cisa <[email protected]>

* Update RELEASES.md

OK @mitchelbaker-cisa  I think all your comments are covered in the new changes I'm pushing... let me know, and I'll let you or roger go ahead and merge this

---------

Co-authored-by: mitchelbaker-cisa <[email protected]>

CONTRIBUTING.md

@@ -31,10 +31,10 @@ Below are some loose requirements we'd like all PR's to follow. Our release proc
 
 ### Quality assurance and code reviews
 
-All PRs will be tested, vetted, and reviewed by our team before being merged with the main code base. All should be pull requested into whatever the upcoming release branch is. Find that by searching for the highest SEMVER `release-X.Y.Z` branch or following our release documentation.
+All PRs will be tested, vetted, and reviewed by our team before being merged with the main code base. All should be pull requested into the `develop` branch. 
 
-### Steps to submit a PR
-	- All PRs should request merges back into LME's *CLOSEST* Major or Minor upcoming release branch `release-X.Y.Z`. This will be viewable in the branch list on Github. You can also refer to our release documentation for guidance. 
+### Steps to submit a PR  
+  - All PRs should request merges back into LME's `develop` branch.  This will be viewable in the branch list on Github. You can also refer to our [release documentation](https://github.com/cisagov/LME/blob/main/RELEASES.md) for guidance. If the fix fits the requirements for a hotfix, the LME team will modify your PR as is relevant.  
   - If the PR corresponds to an issue we are already tracking on LME's public Github [project](https://github.com/orgs/cisagov/projects/68), please comment the PR in the issue, and we will update the issue. 
   - If the PR does not have an issue, please create a new issue and name your branch according to the conventions [here](#branch-naming-conventions). Add a comment at the top of the pull request describing the PR and how it fits into LME's project/code. If the PR follows our other requirements listed here, we'll add it into our public project linked previously.
   - We'll work with you to mold it to our development goals/process, so your work can be merged into LME and your Github profile gets credit for the contributions. 

RELEASES.md

@@ -6,37 +6,61 @@ Our versioning scheme for LME adheres to [SEMVER 2.0](https://semver.org/):  X.Y
 The patch versions will generally adhere to the following guidelines:
 1. Major SEMVER: Denotes a major release, e.g., a new capability, or LME architecture change.
 2. Minor SEMVER: Denotes updates which are less than major but introduces noticeable changes.
-3. Patch SEMVER: Fix bug issues or vulnerability issues but do not introduce new features or updates.
+3. Patch SEMVER: Fix product breaking bugs, or vulnerabilities, or key documentation issues, but do not introduce new features or updates.
 
 ### Timelines
 
 Development lifecycle timelines will vary depending on project goals, tasking, community contributions, and vision.
 
 
-## Current Release Branch:
-To determine the current release branch, it will either be clearly documented in our wiki or on our public [project](https://github.com/orgs/cisagov/projects/68) board. The below example can also be used to determine our current release branch.
-
-- For example, if the current latest release (as seen on the main [README](/README.md)) version `1.1.0`, and the `release-*` branches are: `release-1.1.1` and `release-1.2.0` then the `1.2.0` branch would be the branch where submit the PR, since it is the closest release that is a Major or Minor release, while 1.1.1 is a patch release.
-
-- All `release-*` have various branch protections enabled, and will require review by the development team before being merged.
-The team requests a brief description if one submits a fix for a current issue on the public project, that context will allow us to help determine if it warrants inclusion. If the PR is well documented following our processes in our CONTRIBUTING.md, it will most likely be worked into LME. We value inclusion and recognize the importance of the open-source community.
-
+## Branch Convention:
+We are using a Github flow denoted by: 
+
+![git-flow](/docs/imgs/git-flow.png)
+
+The team requests a brief description if you submit a fix for a current issue on the public project, that context will allow us to help determine if it warrants inclusion. If the PR is well documented following our processes in our [CONTRIBUTING.md](https://github.com/cisagov/LME/blob/main/CONTRIBUTING.md), it will most likely be worked into LME. We value inclusion and recognize the importance of the open-source community.
+
+### Branch Naming Explained: 
+We have 2 main branches whose names will stay constant:
+  1. The `main` branch tracks Major/Minor/Patch releases only, and is only updated with merges from the `develop` or a `hotfix` branch. Releases are tagged appropriate SEMVERs based on their content:  `vX.Y.Z`.
+  2. The `develop` branch is our working copy of latest changes, and tracks all feature development. Feature branches are merged into `develop` as features are added, and when ready `develop` will merge into main as documented above.
+
+There are 2 other branch naming conventions that change based on the issue/update/content they add to the project. 
+  1. A `hotfix` branch is created to "fix" or "patch" a critical issue in the `main` branch of the LME repository. Hotfixes are branched from `main` and merged into `develop`. This way `main` can get fixes, and `develop` will be synced with `main`. This process side-steps the normal `feature` -> `develop` -> commit release -> `main` workflow. Once the hotfix PR is finalized/approved, and merged into main, finally we execute a merge commit of `main` into `develop`.  
+    - It uses the convention: `hotfix-<username>-<issue#>-<shortstring>`  
+    - An example: `hotfix-cbaxley-222-fix-the-pipeline`  
+  2. A feature branch is created from `develop` to add content for issues/work/updates/etc...  
+    - It uses the convention: `<username>-<issue #>-shortstring`  
+    - An example: `mreeve-22-filter-events`  
+
+**NOTE:** Each branch name will have a short string to describe what it is solving for example `create-new-container`.
+
+### Post merge: 
+Any branch other than develop/main should be deleted to preserve readability in github's UI. 
+
+Commands to merge main back into develop: 
+```bash
+#in a previously cloned LME git repository:
+git pull
+git checkout develop
+git merge main
+#push up the new develop branch that is synced with main
+git push -f
+```
 ## Content: 
 
 Each release generally notes the Additions, Changes, and Fixes addressed in the release and the contributors that provided code for the release. Additionally, relevant builds of the release will be attached with the release. Tagging the release will correspond with its originating branch's SEMVER number.
 
 ## Update Process:
-Developments and changes will accrue in a release-X.Y.Z branch according to the level of the release as documented in [Pull Requests](#pull-requests). The process of merging all changes into a release branch and preparing it for release is documented below.
 
 ### Code Freeze:
-Each code freeze will have an announced end date/time in accordance with our public [project](https://github.com/orgs/cisagov/projects/68). Any PRs with new content will need to be in by the announced time in order to be included into the release.
+Each code freeze will have an announced end date/time in accordance with our public [project](https://github.com/orgs/cisagov/projects/68). Any PRs with new content will need to be merged into `develop` by the announced time in order to be included into the release.
 
 ### Steps:
 
-1. Goals/changes/updates to LME will be tracked in LME's public [project](https://github.com/orgs/cisagov/projects/68). These updates to LME will be tracked by pull requests (and may be backed by corresponding issues for documentation purposes for documentation purposes) to a specific `release-X.Y.Z` branch.
-2. As commits are pushed to the PRs set to pull into a release branch, we will determine a time to cease developments. When its determined the features developed in a `release` branch meet a goal or publish point, we will merge all the release's PR's into one combined state onto the `release-.X.Y.Z` branch. This will make sure all testing happens from a unified branch state, and will minimize the number of merge conflicts that occur, easing coordination of merge conflicts. 
-3. Once all work has been merged into an initial release, we will mark the pull request for the release with a `code freeze` label to denote that the release is no longer excepting new features/developments/etc...., all PRs that commit to the release branch should only be to fix breaking changes or failed tests. We’ll also invite the community to pull the frozen `release` branch to test and validate if the new changes cause issues in their environment.
-4. Finally, when all testing and community feedback is complete we'll merge into main with a new tag denoting the `release-X.Y.Z` SEMVER value `X.Y.Z`.
+1. Goals/changes/updates to LME will be tracked in LME's public [project](https://github.com/orgs/cisagov/projects/68). These updates to LME will be tracked by pull requests (and may be backed by corresponding issues for documentation purposes for documentation purposes) into the `develop`  branch.
+2. As commits are pushed to the PRs set to pull into the `develop` branch, we will determine a time to cease developments, and mark a period of testing for `development` that will be merged into main.
+3. When its determined the features developed meet a goal or publish point, after waiting for feedback and proper testing,  we will merge `develop` with a `vX.Y.Z` semver tag into `main` branch.  
 
 ### Caveats:
 Major or Minor SEMVER LME versions will only be pushed to `main` with testing and validation of code to ensure stability and compatibility. However, new major changes will not always be backwards compatible.