We need development branches!

[zepumph]

@samreid and I have been working on https://github.com/orgs/phetsims/projects/94/views/6 over the past few iterations and trying to make progress on main is totally untenable. Also creating N branches per repo is more boilerplate than needed. My vote is for a consistently named branch in every repo called "development".

Note that this also bit a use in our scenery stack community. We need to stop developing on main.

Steps:

1. Do we like the name "development"? I do, but it is a bit long to type in the terminal.
2. Note that currently there are a few one-off branches called development. Those should be renamed or deleted for clarity before doing anything here.
3. Tool to checkout all development branches (and create/track if not created).
4. Tool to merge all branches (probably just for-each.sh is fine for now).
5. Process for knowing what devs are working on development branches so that we know when we can merge to main. Likely this isn't going to be too challenging, since few devs work in cross-repo scary changes for extended periods of time.

[zepumph]

Supporting dev branches on ct:

@samreid feel like it may not be too challenging to get the CT main server set up to run on branches called development. We potentially found only three spots that would need changing (searching for 'main' and cloning).

[zepumph]

We were in the process of trying to use the development branches from last week this morning and had an extensive investigation about how to sync main back into development branches. We found three potential ways forward:

1. with development checked out, git merge main. This resulted in unexpected conflicts and did not successfully make development be "exactly" main. This strategy may be necessary though if multiple devs/projects were working on development branches.
2. Forcively point the dev branch to the sha at main. Then force push to overwrite origin:
   git branch -f development SHA
git push -f
   We found that another computer was able to seamlessly checkout and pull this change. Notes about this: 1. You CANNOT be on development branch when running this. Also, it is easier to type this instead of knowing the sha: git branch -f development main (still need to force push)
3. Delete the branch locally and create it again from the tip of main. Again we needed to force push (while also setting up tracking with origin). Pretty equal to (2), it was equally as seemless on the other-dev side in pulling the changes.

It looked like this to pull after the force push:

 mjkauzmann ~/PHET/git/perennial (development)
 $ git pull
From https://github.com/phetsims/perennial
 + 92293a9...3feacdc development -> origin/development  (forced update)
Successfully rebased and updated refs/heads/development.

[zepumph]

• We need to be able to run pre-commit hooks from development branches, and likely feature branches too: https://github.com/phetsims/phet-info/blob/9dfa88c2fffa800786c5232eaa671e3825d67d7b/git-template-dir/hooks/pre-commit#L12-L13

[zepumph]

Running this script in chipper and perennial was a nice starting point for the next time I wanted to use development branches.

git checkout main
git pull
git branch -f development main
git checkout development
git push -f

[zepumph]

If the above bash script is called sh.sh, here is a js script that can be used to update the development branches to point to main:

import child_process from 'child_process';

( async () => {
  const branch = 'development';
  const results = child_process.execSync( `git branch --list ${branch}`, { shell: true } );

  const hasDevBranch = results.toString().trim().length > 0;
  hasDevBranch && child_process.execSync( 'bash ../sandbox/sh.sh', { shell: true, stdio: 'inherit' } )
} )();

[samreid]

An alternate approach to keep main more stable:

1. Rename “main” to “development” everywhere. We do development in “development”. When CT is green and there are no “blocks publication” issues, we can merge to main. CT can test “development” branches and “main” branches.
2. Create named tag releases at check points, add a change log, etc.
3. Sim developers can develop against “main” or “development” at their discretion. Developers that want to work against “main” can reduce friction and reduce undue hardship on them.
4. Not sure how this will impact things like phet-lib, or if we want to publish a npm module to develop from.

[jessegreenberg]

Some other thoughts about working in branches in phetsims/phet-info#222.

[samreid]

Other ideas written in phetsims/chipper#1345