From a875f04aa07aebb89fa35eb47e8539537a22b92f Mon Sep 17 00:00:00 2001
From: Sean Carroll <scarroll@gitlab.com>
Date: Mon, 19 Feb 2024 15:46:34 +0000
Subject: [PATCH] Protected branch Workflow docs

---
 .../authorization_for_merge_requests.md       | 25 +++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/doc/user/project/merge_requests/authorization_for_merge_requests.md b/doc/user/project/merge_requests/authorization_for_merge_requests.md
index 1cfd66f5b2b43..a1a77fb4d049a 100644
--- a/doc/user/project/merge_requests/authorization_for_merge_requests.md
+++ b/doc/user/project/merge_requests/authorization_for_merge_requests.md
@@ -40,6 +40,31 @@ protected branch.
 
 - Manual setup of protected branch required for each new project
 
+To set up a protected branch flow:
+
+1. Start with ensuring that your default branch is protected with [default branch protections](../repository/branches/default.md).
+1. If your team has multiple branches, and you would like to manage who can merge changes and who
+   explicitly has the option to push or force push, consider making those branches protected:
+
+   - [Manage and Protect Branches](../repository/branches/index.md#manage-and-protect-branches)
+   - [Protected Branches](../protected_branches.md)
+
+1. Each change to the code comes through as a commit.
+   You can specify the format and security measures such as requiring SSH key signing for changes
+   coming into your code base with push rules:
+
+   - [Push Rules](../repository/push_rules.md)
+
+1. To ensure that the code is reviewed and checked by the right people in your team, use:
+
+   - [Code Owners](../codeowners/index.md)
+   - [Merge Request approval rules](approvals/rules.md)
+
+Also available in the Ultimate tier:
+
+- [Status checks](status_checks.md)
+- [Security Approvals](approvals/rules.md#security-approvals)
+
 ## Forking workflow
 
 With the forking workflow, maintainers get the Maintainer role and regular
-- 
GitLab