From 6dbc2f72b301de5320463549054c5f3b9701f73b Mon Sep 17 00:00:00 2001 From: Clarence Bakosi Date: Fri, 26 Sep 2025 20:46:59 +0100 Subject: [PATCH] fix(curriculum): typo in lecture introduction to git and github (#62383) --- .../688290da3736c273009129d0.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/curriculum/challenges/english/blocks/lecture-introduction-to-git-and-github/688290da3736c273009129d0.md b/curriculum/challenges/english/blocks/lecture-introduction-to-git-and-github/688290da3736c273009129d0.md index 2a8b43898d7..68ec413035d 100644 --- a/curriculum/challenges/english/blocks/lecture-introduction-to-git-and-github/688290da3736c273009129d0.md +++ b/curriculum/challenges/english/blocks/lecture-introduction-to-git-and-github/688290da3736c273009129d0.md @@ -63,7 +63,7 @@ Another option is "Squash and Merge", which takes ALL of the commits from the he Finally, there is "Rebase and Merge", which takes all of the commits, resets them to "come after" the latest commit on the base branch, then merges the head in without a merge commit. Rebasing is a complicated topic that you will learn about in depth later, so it's okay if you do not quite understand it today. -Each open source project will choose whatever merge strategy works best. But because of these differences in behaviour, you should ALWAYS create a new branch to commit your contributions on. Never commit directly to the default `main` branch, or things will get messy when you need to bring the changes down from the original repo. +Each open source project will choose whatever merge strategy works best. But because of these differences in behavior, you should ALWAYS create a new branch to commit your contributions on. Never commit directly to the default `main` branch, or things will get messy when you need to bring the changes down from the original repo. With all of that, you have successfully created and merged your first pull request!