Rename branches to eliminate Berkeley commits from `main` about nmdc-schema

[shreddd]

OK - for now - avoid deleting branches until this is fixed, in case something needs to be restored. This seems ok as an overall plan.

[eecavanna]

In other words, I think the branch renaming solution would have worked; but I accidentally used the wrong branch as the new main branch. 🤦

CC: @aclum

[turbomam]

The nmdc-schema main branch commit history is now free of the delete operations that would have ruined berkeley-schema-fy24

The berkeley-schema-fy24 GH code page shows that it is ~ 1170 commits ahead and 0 commits behind nmdc-schema

[eecavanna]

This is done. Closing.

[turbomam]

@eecavanna @shreddd when will you be comfortable deleting the temporary branches?

[eecavanna]

I'm already comfortable with them being deleted now, based on the validation we did over Zoom this morning.

I'll be even more comfortable (more comfortable than necessary, from my perspective) at the end of the sprint (i.e. in ~10 calendar days). The hypothetical scenario I think would be simplified for us if we were to wait until then is:

• Someone created a feature branch from the main branch (while the main branch was in one of its temporary, problematic states in which it had 1000+ accidental commits on it). Then, that person makes a handful of commits on that feature branch. Finally, that person pushes the feature branch up to GitHub and opens a PR.
• The PR shows 1000+ commits (plus the handful that person actually made)

I think if we have copies of those temporary branches around (which we currently do—they are named main-old and main-old-2), it will be easier for us to make sense of that PR.

I like using the end of the sprint as the milestone here because that is a milestone shared by some developers (e.g. they might open a PR for whatever they're currently working on "by then").