Add workflow to require merge from era branch

[spoopr]

basically the new workflow idea is:

• create an "era branch", like update-to-2026 or post-2026
• make individual feature branches off the era branch (post-2026/delete-breaker), maybe stack feature branches if need be (post-2026/delete-breaker/burn-pdh)
• merge into the era branch with one review per feature branch
• once done with the era branch, merge era branch into main with two reviews

the reason i need to add this workflow thing is cause this structure would be enforced via branch names, and theres no direct method to verify branch name in github rulesets. thus, use a github workflow as a boolean check, then require the check to pass to merge into main.

once this merges, then someones gotta add the require status checks to pass value in the protect main ruleset

[spoopr]

oh and like, this is a proposal. yall are in charge now, so take it or leave it if you wanna

[spoopr]

i guess i specify some more: the reason why i think we should implement this workflow in the first place is cause i think it would help us move away from the "superbranch" system we sort-of have going on. we've managed to mitigate this problem somewhat by regularly pushing and merging and branching again, so it's not as bad as previous years, but I think we can do better.

ultimately, what I think would work best for us is if we made wayy to many branches than we need then merge them in as we're able to get testing time. when working on the season robot code repo, that would give as a loop something like:

1. given whatever feature goal you have, decide on a topic name, say fire-into-the-crowd. from hereon out, there cannot exist a branch of such name, or git will throw a fit.
2. make a new, uhhhh, "workspace" branch (or feature branch, idk, shoot me), fire-into-the-crowd/workspace.
   while git will not allow both fire-into-the-crowd and fire-into-the-crowd/{anything else} to exist, git will allow multiple fire-into-the-crowd/{somethings} to exist.
   in github:robot-base, I'm calling those era branches, but that doesn't really make sense for a season repo, so i suggested the workspace name.
3. as needed and as reasonable, make subfeature branches, such as fire-into-the-crowd/launcher or fire-into-the-crowd/yaw.
   if you're able to layout ahead of time or are able to rearrange the branches locally and on the github repo, you can also organize the branch names in sub-subfeatures, like fire-into-the-crowd/aiming/vision and fire-into-the-crowd/aiming/encoder or something.
   one important thing to consider, though is the layout of branched, sequential subfeatures, like if fire-into-the-crowd/launcher had the sequential subfeature branch fire-into-the-crowd/foc-control. honestly, i'm not sure how to best handle such a naming scheme, as--assuming you're unable to rename branches--you are unable to use another slash in the name of the sub-subfeature. git logs will help, though.

from here, you can take one of two approaches:
4a. roll up with the robot

• start off the workspace branch (fire-into-the-crowd/workspace),
• merge in the first subfeature branch (fire-into-the-crowd/launcher), then
• test, debug, test again, whatever.
• from there, pick the next subfeature, maybe a sequential subfeature (fire-into-the-crowd/foc-control) or a parallel subfeature (fire-into-the-crowd/yaw)
• repeat until all subbranches are gone and code is usable

4b. no robot :(

• start off from a subfeature (fire-into-the-crowd/launcher)
• review the changes it would make to the workspace branch, don't merge quite yet.
• pick a sequential subfeature, if such exists (fire-into-the-crowd/foc-control)
• repeat until you're out of sub-sub-subs-busubs-features, then merge upwards until you're back at the original subfeature (fire-into-the-crowd/launcher).
  the goal is basically to "collapse" all subfeatures, in prep for robot time
• wait for robot
• see step 3a, but this time, you now only have to merge the first-layer subfeature.

5. review completed workspace branch again, then merge into main.
6. pick a new goal, and restart from step 1.

I think this would help us get away from the issue we've had this year, that of trying to separate the driverstation--the control terminal--and the driverstation--the thing that holds the master copy. i thought using the driverstation would be a workable solution, but given the friction thats added to our iteration process, we should try something better.

one thing to consider is that this approach essentially implies that all shop time is testing and debugging; all code should be made, organized, and published ahead of time. frankly, thats the point, though.

---

thats the spiel, time for semantics.

both github:robot-base and github:RobotCode202X can use variations on this approach, but github:robot-base could use slightly stricter guardrails. on github:robot-base, I currently have it set so that all subfeature branches (something like post-2026/rewrite-limelights-again-again-again) require one review before merging, as apposed to none in github:RobotCode202X. similarly, feature branches merging into main require two reviews in github:robot-base, instead of one in github:RobotCode202X.

the rationale for this choice is that we (as a team) are focusing on other things than testing code and robot, so we can't really say a github:robot-base subfeature will be as tested as a github:RobotCode202X subfeature. in the same vein, as completing a pull request in github:robot-base is altering the template code rather than the forked code, that's essentially equivalent to making the changes to all github:RobotCode202X repos to ever be made. also, we just need to move quicker during build season.

[spoopr]

also, i made another branch ruleset for merging into feature branches. its disabled, currently

before this merges, i wanna make a check to look for unmerged subfeature branches, too.

[spoopr]

an amendment to the previous explaination:

I thought that the /es in git naming was allowed; to clarify, they are, but with a caveat: git requires that, given a branch of name x/y, there must not exist a branch of name x.

anyways, that kinda messes up the whole idea i had. lemme rethink it. rethunk

[spoopr]

after thinking for a while, i realize that there's some solid drawbacks to this approach. first off,

1. your git branches are going to look like spaghetti

sucks, but I think this would be inevitable in any sufficiently large project. after dealing with my stuff for a season, i think yall'll be able to figure it out.

2. branch naming can become ambiguous

like in the example: fire-into-the-crowd/launcher and fire-into-the-crowd/foc-control. to someone who knows what they're talking about, it might be obvious that they're sequential features, but its not instantly recognizable to someone else. better than nothing, i'd say, but who knows.

3. abstract conventions

again, to someone who's trying to enter the project, they might struggle to understand which branch to work on and how, and that'll pit them against the branch protections. then again, i'd again say that's the type of bureaucracy inevitable with any project.