diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 7eaf501..5081d3d 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -44,6 +44,14 @@ If you look at [the list of issues](https://gitlab.com/tildes/tildes/issues), th
 
 Once you've selected an issue to work on, please leave a comment saying so. This will allow other people to see that they shouldn't also start on that issue.
 
+### Git branches
+
+<small>*Updated in July 2025*</small>
+
+Contributions should be made on top of the latest `develop-<version>` Git branch. For example, if you see `develop-1.101` and `develop-1.102`, and nothing later than that, then create your feature branch off of `develop-1.102`. When submitting the merge request, please ensure it is targeting that branch also.
+
+Please avoid submitting merge requests directly to `master`. Our `develop-<version>` and `staging-<version>` branches are set up to streamline code reviews and testing before merging to `master`. The `master` branch generally reflects what is running live on the main site.
+
 ### Before submitting a merge request
 
 After you've finished making your changes, there are a few things to check before proposing your changes as a merge request.
@@ -57,3 +65,25 @@ Squash your changes into logical commits. For many changes there should only be
 Once your code is ready, you can [submit a new merge request on GitLab](https://gitlab.com/tildes/tildes/merge_requests/new).
 
 After creating the merge request, if you need to make any further changes to your code (whether in response to code review or not), please add the changes as new commits. Do not modify the existing commits, this makes it far simpler for other people to follow what changes you're making. Once the merge request is approved, a final pass can be done to squash the commits down, make updates to commit messages, etc. before it's actually merged.
+
+
+# Notes for Maintainers
+
+This section contains notes for Tildes code repository maintainers. If you are a code contributor, **you can safely ignore this entire section**.
+
+## [For Maintainers] Cutting new versions
+
+1. Merge/cherry-pick changes to `master`. Generally coming from latest `staging-<version>` branch.
+2. Bump the `tildes/package.json` version on `master`. E.g. to `"1.101.0"`.
+3. Add a Git tag on the commit that bumped the `package.json` version:
+
+    $ git tag -a -m'Automatically insert meme GIF links every other post' v1.101.0
+
+4. Create new `staging-<version>` and `develop-<version>` branches for the **next** version:
+
+    $ git branch -c master staging-1.102
+    $ git branch -c master develop-1.102
+
+5. Push the new tag and branches to the main Tildes repo (assuming Git remote named `upstream`):
+
+    $ git push --follow-tags upstream master staging-1.102 develop-1.102
\ No newline at end of file