Add docs

Author: mydea

CONTRIBUTING.md

@@ -130,25 +130,14 @@ This means that all commits on the branch will be squashed into a single commit,
 * Make sure to rebase the branch on `master` before squashing it
 * Make sure to update the commit message of the squashed branch to follow the commit guidelines - including the PR number
 
-## Publishing a Release
+### Gitflow
 
-_These steps are only relevant to Sentry employees when preparing and publishing a new SDK release._
+We use [Gitflow](https://docs.github.com/en/get-started/quickstart/github-flow) as a branching model.
 
-**If you want to release a new SDK for the first time, be sure to follow the [New SDK Release Checklist](./docs/new-sdk-release-checklist.md)**
+For more details, [see our Gitflow docs](./docs/gitflow.md).
 
-1. Determine what version will be released (we use [semver](https://semver.org)).
-2. Update [`CHANGELOG.md`](https://github.com/getsentry/sentry-javascript/edit/master/CHANGELOG.md) to add an entry for the next release number and a list of changes since the last release. (See details below.)
-3. Run the [Prepare Release](https://github.com/getsentry/sentry-javascript/actions/workflows/release.yml) workflow.
-4. A new issue should appear in https://github.com/getsentry/publish/issues.
-5. Ask a member of the [@getsentry/releases team](https://github.com/orgs/getsentry/teams/releases/members) to approve the release.
+## Publishing a Release
 
-### Updating the Changelog
+_These steps are only relevant to Sentry employees when preparing and publishing a new SDK release._
 
-1. Create a new branch.
-2. Run `git log --format="- %s"` and copy everything since the last release.
-3. Create a new section in the changelog, deciding based on the changes whether it should be a minor bump or a patch release.
-4. Paste in the logs you copied earlier.
-5. Delete any which aren't user-facing changes.
-6. Alphabetize the rest.
-7. If any of the PRs are from external contributors, include underneath the commits `Work in this release contributed by <list of external contributors' GitHub usernames>. Thank you for your contributions!`. If there's only one external PR, don't forget to remove the final `s`. If there are three or more, use an Oxford comma. (It's in the Sentry styleguide!)
-8. Commit, push, and open a PR with the title `meta: Update changelog for <fill in relevant version here>`.
+[See the docs for publishing a release](./docs/publishing-a-release.md)

docs/gitflow.md

@@ -0,0 +1,11 @@
+# Gitflow
+
+We use [Gitflow](https://docs.github.com/en/get-started/quickstart/github-flow) as a branching model.
+
+## Summary
+
+* Ongoing work happens on the `develop` branch
+* Any PRs (features, ...) are implemented as PRs against `develop`
+* When we are ready to release, we merge develop into master, create a release there, then merge master back into develop
+* Whatever is currently on `master` can be considered the last released state of the SDK
+* Never merge directly into `master` (unless we want e.g. an emergency bugfix release)

docs/publishing-a-release.md

@@ -0,0 +1,24 @@
+
+# Publishing a Release
+
+_These steps are only relevant to Sentry employees when preparing and publishing a new SDK release._
+
+**If you want to release a new SDK for the first time, be sure to follow the [New SDK Release Checklist](./new-sdk-release-checklist.md)**
+
+1. Determine what version will be released (we use [semver](https://semver.org)).
+2. Update [`CHANGELOG.md`](https://github.com/getsentry/sentry-javascript/edit/master/CHANGELOG.md) to add an entry for the next release number and a list of changes since the last release. (See details below.)
+3. Run the [Prepare Release](https://github.com/getsentry/sentry-javascript/actions/workflows/release.yml) workflow.
+4. A new issue should appear in https://github.com/getsentry/publish/issues.
+5. Ask a member of the [@getsentry/releases team](https://github.com/orgs/getsentry/teams/releases/members) to approve the release.
+6. Automated CI workflows will take care of syncing changes between `develop` and `master`
+
+## Updating the Changelog
+
+1. Create a new branch.
+2. Run `git log --format="- %s"` and copy everything since the last release.
+3. Create a new section in the changelog, deciding based on the changes whether it should be a minor bump or a patch release.
+4. Paste in the logs you copied earlier.
+5. Delete any which aren't user-facing changes.
+6. Alphabetize the rest.
+7. If any of the PRs are from external contributors, include underneath the commits `Work in this release contributed by <list of external contributors' GitHub usernames>. Thank you for your contributions!`. If there's only one external PR, don't forget to remove the final `s`. If there are three or more, use an Oxford comma. (It's in the Sentry styleguide!)
+8. Commit, push, and open a PR with the title `meta: Update changelog for <fill in relevant version here>` against `develop` branch.