diff --git a/_episodes/41-code-review.md b/_episodes/41-code-review.md
index 6abc54810..89c137b95 100644
--- a/_episodes/41-code-review.md
+++ b/_episodes/41-code-review.md
@@ -24,9 +24,17 @@ so in this episode we'll be looking at how to manage the process of team softwar
 code by engaging in code review process with other team members.
 
 > ## Collaborative Code Development Models
-> The way your team provides contributions to the shared codebase depends on the type of development model you use in your project. 
+
+The way your team provides contributions to the shared codebase depends on the type of development model you use in your project. 
+
 Two commonly used models are:
-- **fork and pull model** - where anyone can **fork** an existing repository (to create their copy of the project linked to 
+
+ * Fork and pull model
+ * Shared repository model
+
+### Fork and Pull Model
+
+Where anyone can **fork** an existing repository (to create their copy of the project linked to 
 the source) and push changes to their personal fork. 
 A contributor can work independently on their own fork as they 
 do not need permissions on the source repository to push modifications to a fork they own. 
@@ -36,13 +44,26 @@ source projects as it reduces the start up costs for new contributors and allows
 independently without upfront coordination with source project maintainers. So, for example, 
 you may use this model when you are an 
 external collaborator on a project rather than a core team member.
-- **shared repository model** - where collaborators are granted push access to a single shared code repository. 
-Even though collaborators have write access to the main 
-development and production branches, the best practice of creating feature branches for new developments and 
-when changes need to be made is still followed. This is to enable easier testing of the new code and 
+
+### Shared Repository Model
+
+Where collaborators are granted push access to a single shared code repository. 
+By default, collaborators have write access to the main branch. 
+However, best practises is to create feature branches for new developments, and protect the main branch. 
+This is to enable easier testing of the new code and 
 initiate code review and general discussion about a set of changes before they are merged 
-into the development branch. This model is more prevalent with teams and organisations 
-collaborating on private projects.
+into the development branch. 
+This model is more prevalent with teams and organisations collaborating on private projects.
+It also helps to keep the main branch stable, making it easier for other developers to work on the code. 
+
+To protect the main branch in GitHub, go to the repository settings, select `Branches`. Click `Add Rule`. Type in the name of your main branch (e.g. `main` and/or `develop`). Tick the check box saying require pull requests. This will ensure all changes to the branch are done via a pull request. 
+
+![GitHub add a branch protection rule settings screen with recommended settings enabled for a branch called main](../fig/github-branch-protection-settings.png)
+
+It is recomended to also tick `Require approvals` and `Require status checks before merging`. The first means someone besides the person who raised the pull request will need to approve the change. The second ensures that CI has run succesfully before allowing the changes to be made. 
+
+See [GitHubs documentation for more information about protecting branches](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule). 
+
 {: .callout}
  
 Regardless of the collaborative code development model you and your collaborators use - code reviews are one of the 
diff --git a/fig/github-branch-protection-settings.png b/fig/github-branch-protection-settings.png
new file mode 100644
index 000000000..08c5697a4
Binary files /dev/null and b/fig/github-branch-protection-settings.png differ