From 2e612cb1a6dd4047878f517835cd6c32c69d4966 Mon Sep 17 00:00:00 2001 From: Michael Reeves <147089975+mreeve-snl@users.noreply.github.com> Date: Thu, 5 Dec 2024 14:11:58 -0500 Subject: [PATCH] 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 --- RELEASES.md | 34 +++++++++++++++++++++++----------- 1 file changed, 23 insertions(+), 11 deletions(-) diff --git a/RELEASES.md b/RELEASES.md index 60421216..070c24ac 100644 --- a/RELEASES.md +++ b/RELEASES.md @@ -15,9 +15,10 @@ Development lifecycle timelines will vary depending on project goals, tasking, c ## 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, it will most likely be worked into LME. We value inclusion and recognize the importance of the open-source community. +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: @@ -25,16 +26,27 @@ We have 2 main branches whose names will stay constant: 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`. - - It uses the convention: `hotfix---` - - 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: --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`: - - + 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---` + - 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: `--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.