Skip to content

More small fixes #155

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
alexdewar merged 5 commits into from
Feb 3, 2026
Merged

More small fixes #155

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
de3c55e
"in you" => "in your"
alexdewar Jan 30, 2026
c411c33
Fix missing discussion panel in managing contributions episode
alexdewar Jan 30, 2026
a3792d6
Quotes to backticks
alexdewar Jan 30, 2026
0fd389c
Indentation
alexdewar Jan 30, 2026
003055c
fulfil => fulfilled
alexdewar Jan 30, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions episodes/04-rewriting_history.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
2 changes: 1 addition & 1 deletion episodes/07-managing_contributions.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Copy link
Copy Markdown

@AdrianDAlessandro AdrianDAlessandro Jan 30, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense. But I've just noticed when looking at the live version of the notes that it says "Discussion" of "Callout" as the heading for all of these sections. I would be much better if this title was the actual heading we want for these sections. Do we know if this is possible?

Copy link
Copy Markdown

@SaranjeetKaur SaranjeetKaur Feb 3, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@AdrianDAlessandro from what I can tell, these different sections are created using special tags ( discussion, prereq, challenge etc.) on the respective fenced div.

The actual heading would usually go inside the fenced div, similar to how we write a heading in markdown. So something like:

:::::::::: discussion

##  Pull Requests in GitHub

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aenean commodo ligula eget dolor. Aenean massa.

::::::::::

As an example, refer the use of challenge tag and its header in this git novice lesson by Software Carpentry.


## Why the name?

Expand Down
4 changes: 2 additions & 2 deletions episodes/08-continuous_integration.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down Expand Up @@ -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
Expand Down