In the Wizards of the Wiki guild, janetmango asked "does the beta site use the same repositories? I'm just wondering how features go through the beta process." The long answer below is an attempt to teach her the dangers of asking questions. ;)
First some background about GitHub (with footnotes!):
GitHub has the concept of "branches". A branch is a complete copy of the website [1] but with certain differences, such as new code to fix a bug or create a new feature. There can be multiple branches in a repository, with each one being used to work on a different feature. In our GitHub repository, the main branch is called `develop` and it is the same as the production website but with a few extra pieces of new code that have been recently approved and will go live within a few days.
When `develop` is made live we usually deploy [2] it to both production [3] and beta at the same time, just to keep the two sites in sync. If `develop` contains very big or important changes (e.g., a new Grand Gala) we will often deploy it to beta first, test it for a few minutes or a few hours (depending on the changes), and then deploy it to the main site.
However sometimes the beta site is used differently. There might be a large body of new code being written that will be significantly different than the current production site and that will take many days or weeks to create and test. [4] That code will be in a different GitHub branch [5], which means that it can be changed without affecting anything in the `develop` branch. When the code is at a stage that is suitable for at least some testing to be done, it is deployed to the beta site, and then the beta site is not used for anything else until the testing is finished [6]. When we're happy with the new code, we will merge it into `develop` and then deploy it to production. [7]
Footnotes:
[1] Or a complete copy of a program's source code or of whatever is being maintained in GitHub.
[2] Deploy means copy, usually with the implication that something is being copied from a development or testing environment to the "live" or "real" environment; I'm not sure how common that usage of "deploy" is outside of IT.
[3] "production" is https://habitrpg.com/
[4] E.g., at the moment we are redesigning almost all of the skills to make them more balanced (some stronger, some weaker).
[5] But in the same repository. A repository is a collection of branches, issues (bug reports), pull requests and commits (new features or bug fixes), documentation, etc. Basically, it's everything involved with an entire website (or an entire program). HabitRPG has one repository called habitrpg for the website (with many branches in it), and another repository called habitrpg-mobile for the mobile app.
[6] Although if there is an urgent reason to do some short-term testing for another feature, we will temporarily overwrite beta with `develop` or another branch, but then soon re-deploy the long-term project's branch to beta.
[7] One of the great benefits of GitHub (and git, the program that GitHub is based on) is that it makes merging two branches together incredibly easy, even if the branches have very different code in them. Git has some extremely advanced logic that allows it to recognise how two versions of one file should be combined into a single version. In many cases, it will correctly work out for itself which pieces of one file should override which pieces the other, and when it can't work that out (because there is a "conflict" between two pieces), it puts both pieces into one file but clearly marks them as being a conflict, so that a human can sort out what should be done. It doesn't let you proceed further in the merging/committing/deploying process until all conflicts have been handled (that's a useful safety feature). I love git. :)