differences for PR #155

Author: actions-user

04-rewriting_history.md

@@ -312,8 +312,8 @@ copy of a repository.
 
 ### Removing branches once you are done with them is good practice
 
-Over time, you will accumulate lots of branches to implement different features in you
-code. It is good practice to remove them once they have fulfil their purpose. You can do
+Over time, you will accumulate lots of branches to implement different features in your
+code. It is good practice to remove them once they have fulfilled their purpose. You can do
 that using the `-D` flag with the `git branch` command:
 
 ```bash

07-managing_contributions.md

@@ -66,7 +66,7 @@ Developer 2 -- "Hmmm... if we tweak things here then it might be faster."
 
 Pull requests are a GitHub feature which allows collaborators tell each other about changes that have been pushed to a branch in a repository. Similar to **issues**, an open pull request can contain discussions about the requested changes and allows collaborators to review proposed amendments and follow-up commits before changes are either rejected or accepted and merged into the base branch.
 
-::::::::::::::::::::::::::::::::::::::  objectives
+::::::::::::::::::::::::::::::::::::::  discussion
 
 ## Why the name?
 

08-continuous_integration.md

@@ -129,7 +129,7 @@ on:
 ```
 
 This will additionally trigger the workflow to run when a pull request is created. The
-"push" and "pull\_request" triggers are probably the most commonly used however, there
+`push` and `pull_request` triggers are probably the most commonly used however, there
 are a great many available (see [GitHub Docs: Events that trigger
 workflows][actions-triggers]). This is an example of where GitHub Actions goes further
 than most CI systems as you can automate pretty much any behaviour in a repository.
@@ -274,7 +274,7 @@ take things further by implementing some policy in the form of a "branch protect
 rule". We can use this to put two restrictions in place:
 
 1. No code can be pushed directly to the `main` branch, it must always be added via pull
-  request.
+   request.
 2. All CI workflows must succeed in order for PRs to be allowed to merge.
 
 Combined together these rules mean that **no code can end up in the `main` branch if it

md5sum.txt

@@ -7,11 +7,11 @@
 "episodes/01-collaborating_with_git.md" "b9d1e525a1019a4d65d5c6c832cf9aa4" "site/built/01-collaborating_with_git.md" "2026-01-28"
 "episodes/02-branching_merging.md" "13d298ecafff6759ce64cefdb3d2cd92" "site/built/02-branching_merging.md" "2026-01-28"
 "episodes/03-merge_conflicts.md" "eb9a21399cbee1e268ae0716132e45f7" "site/built/03-merge_conflicts.md" "2026-01-28"
-"episodes/04-rewriting_history.md" "afb7b1d917416531e47eed761c7f03f1" "site/built/04-rewriting_history.md" "2026-01-28"
+"episodes/04-rewriting_history.md" "3cf430c1da1144b5fefe8c4fb18b602f" "site/built/04-rewriting_history.md" "2026-01-30"
 "episodes/05-pulling_pushing.md" "b8c48be3fbbbe83aac8438dfed6a3090" "site/built/05-pulling_pushing.md" "2026-01-28"
 "episodes/06-first_session_end.md" "23bef32763ef61227f4453f3e653e71c" "site/built/06-first_session_end.md" "2025-11-13"
-"episodes/07-managing_contributions.md" "b97c35aafbef67a001c3b364940b97bd" "site/built/07-managing_contributions.md" "2026-01-28"
-"episodes/08-continuous_integration.md" "a85d665ea5dcfa570f97481ff3ee03a3" "site/built/08-continuous_integration.md" "2026-01-28"
+"episodes/07-managing_contributions.md" "f04d56dc9ce27a20d99f7d6ff2638288" "site/built/07-managing_contributions.md" "2026-01-30"
+"episodes/08-continuous_integration.md" "f2fe1dbdb1ec2ddf52bf128e2727ea76" "site/built/08-continuous_integration.md" "2026-01-30"
 "episodes/09-releases_tags.md" "b3c01519512f575f6a65fe12617bba43" "site/built/09-releases_tags.md" "2026-01-28"
 "episodes/10-collaborative_development.md" "5a65ba4870f9ad3b6466a3e8ee6da167" "site/built/10-collaborative_development.md" "2026-01-28"
 "episodes/11-second_session_end.md" "013ad4a6db48f16b26fdc51d7035eb1f" "site/built/11-second_session_end.md" "2025-11-13"