docs(gitflow): reconcile GITFLOW.adoc with the main branch reset - #1213
Merged
Merged
Conversation
main had drifted ~1,800 commits behind develop (stuck at 0.2.0) because the "merge release branch to main" step had been opened as a PR for every release and closed unmerged every time -- develop was already the real default branch and the actual publish trigger (a pushed tag), so nothing enforced main staying current, and it didn't. Rather than reconcile that drift, main was renamed to legacy (full history preserved there) and a new main created at the 0.51.0 tag. This updates the process doc to match: - main Branch: now described as "tracks the last published release," with a dated note explaining the reset and where the old history lives. - Release Process: rewritten to the actual sequence -- tag lives on the release branch's own commit (the publish workflow triggers on the tag push, independent of main), and merging main up to the release is an explicit manual step taken only after that publish goes green, not before and not automatically. - Branch Protection Rules / Publishing: corrected to reality (develop is protected; main currently isn't -- flagged as a TODO instead of documenting a protection that doesn't exist). - A note on the workflow diagram flagging that it shows the textbook tag-after-merge shape, not SKaiNET's actual tag-before-merge order.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to today's `main` branch reset (context: SKaiNET#1198 thread).
What happened to main
`main` had drifted ~1,800 commits behind `develop` (stuck at a `0.2.0`-era commit) because the
"merge release branch to main" step had been opened as a PR for every release (most recently
#1200 for 0.50.0) and closed unmerged every time. `develop` was already the project's real
default branch and the actual Maven Central publish trigger is a pushed tag, independent of
`main` — so nothing ever needed main to be current, and it wasn't.
Rather than reconcile ~1,800 commits of drift with no real value in the history itself:
What this PR does
Updates `GITFLOW.adoc` so the process document matches what actually happens, not the aspirational
textbook version:
explaining the reset and where pre-0.51.0 history now lives.
commit (the publish workflow triggers on the tag push, not on `main`), and merging `main` up to
the release is an explicit manual step taken only after that publish goes green. This is the
step every release before 0.51.0 skipped; making it explicit and manual (not automated) is the
actual fix.
(required `build-job` check), `main` currently isn't. Flagged as a TODO rather than documenting
protection that doesn't exist.
SKaiNET's actual tag-before-merge order.
Test plan
found
`GITFLOW.adoc` content (they just point to it), so no docs-site page needed a matching edit