Document the repo's branch protection rules (#50)

### Proposed changes

This commit adds a section on the repo's branch protection rules to the
CONTRIBUTING doc.

If this PR addresses an
[issue](https://github.com/nginx/documentation/issues) on GitHub, ensure
that you link to it here:

Closes #51 

### Checklist

Before creating a PR, run through this checklist and mark each as
complete.

- [x] I have read the [contributing guidelines](/CONTRIBUTING.md)
- [x] I have signed the [F5 Contributor License Agreement
(CLA)](https://github.com/f5/.github/blob/main/CLA/cla-markdown.md)
- [x] If applicable, I have added tests that prove my fix is effective
or that my feature works
- [x] If applicable, I have checked that any relevant tests pass after
adding my changes
- [x] I have updated any relevant documentation
([`README.md`](/README.md) and [`CHANGELOG.md`](/CHANGELOG.md))
- [x] I have rebased my branch onto main
- [x] I will ensure my PR is targeting the main branch and pulling from
my branch from my own fork
- [x] If the change involves:
  - Code
  - Anything that resembles Personally identifying information (PII)
    - Make sure to use placeholders such as `<username>` in place of PII
- URLs (watch for
[typosquatting](https://support.microsoft.com/en-us/topic/what-is-typosquatting-54a18872-8459-4d47-b3e3-d84d9a362eb0))
  - Significant new/revised content
    
In these cases, the change will require at least two (2) approvals
before merging

Author: jputrino

CONTRIBUTING.md

@@ -30,7 +30,7 @@ To suggest a feature or enhancement, open an issue on GitHub with the label
 `feature` or `enhancement` using the available feature request issue template.
 Please ensure the feature or enhancement has not already been suggested.
 
-## Open a discussion
+## Open a Discussion
 
 If you want to start a conversation with the community and maintainers,
 we encourage you to use
@@ -48,7 +48,7 @@ To contribute to F5 NGINX documentation, follow these steps:
 Alternatively, you're welcome to suggest improvements to highlight problems with
 our documentation as described in our [support](./SUPPORT.md) page.
 
-### Git Style Guide
+### Git style guide
 
 - Keep a clean, concise and meaningful Git commit history on your branch, rebasing locally and squashing before you submit a PR
 - Follow the guidelines of writing a good commit message as described here <https://chris.beams.io/posts/git-commit/>
@@ -61,6 +61,15 @@ our documentation as described in our [support](./SUPPORT.md) page.
   - Add more detailed description in the body of the git message (`git commit -a` to give you more space and time in
     your text editor to write a good message instead of `git commit -am`)
 
+#### Branch protection rules
+
+This repository has the following branch protection rules in place:
+
+- **Pushing branches that contain the "internal/" prefix is not allowed.** This ensures internal development branches are not accidentally or purposefully pushed to this repo.
+- **Two approvers are required for all merges to main and release branches.** This ensures all code that is approved for release to production is appropriately reviewed. This rule applies to all branches with `*release*` in the branch name.
+- **Only NGINX DocOps Team members can create release branches.** This ensures the docs team is aware of all branches supporting specific product releases. This rule applies to all branches with `*release*` in the branch name.
+- **Pushes (force or otherwise) directly to main or release branches is not allowed.** Release branches serve as "main" for the release they are associated with. Restricting pushes directly to main and release branches ensures all content changes are reviewed and approved. This rule applies to all branches with `*release*` in the branch name and to "main".
+
 ### Documentation style guide
 
 For detailed guidance, see our documentation [style guide](./templates/style-guide.md).