Merged Documentation and New Git Approach

I’ve cleaned up and resolved the divergences between the branches in the GitHub repository. I also finished an initial first pass of the documentation, so now there’s no more need to rely on an old PDF.

Thanks to Jim Young of ETE Reman for giving us some good fundamental advice on Git workflows.

Going forward now, we’ll adopt a modified trunk strategy, with only two long-lived branches, “main” and “development”.

The main branch contains the current stable version, and the development branch contains the current unstable version. No direct commits should occur to either except in rare circumstances like a critical hotfix. Instead, developers should create short-lived branches off of the development branch, with names that help track their purposes. They can then issue a pull request to have a maintainer review and merge into the development branch. Main should not be the root of a short-lived working branch if possible; these should hit development first, and then be merged either directly from there, or from a release branch that will be removed once it is merged into main.

I still have some questions about how we should set this up securely for a broader audience (for example, what if someone I’ve never met wants to contribute? Should she fork the repository on GitHub and issue the request that way? I’m not sure), but since we’re small at the moment I can start feeling out how this will work and not get hung up on the broader problem.