Merge pull request #5 from esciencecenter-digital-skills/github2gitla…

…b-section4

Change github to gitlab in section 4

_episodes/40-section4-intro.md

@@ -29,7 +29,7 @@ as well as increasing knowledge about the codebase across the team.
 We will thus look at the benefits of reviewing code,
 in particular, the value of this type of activity within a team,
 and how this can fit within various ways of team working.
-We will see how GitHub can support code review activities via pull requests,
+We will see how GitLab can support code review activities via merge requests,
 and how we can do these ourselves making use of best practices.
 
 After that, we will look at some general principles of software maintainability

_episodes/42-software-reuse.md

@@ -135,7 +135,7 @@ some extra syntax to provide ways of formatting them.
 A big advantage of them is that they can be read as plain-text files
 or as source files for rendering them with formatting structures,
 and are very quick to write.
-GitHub provides a very useful [guide to writing Markdown][github-markdown] for its repositories.
+GitHub provides a very useful [guide to writing Markdown][github-markdown] that also applies to GitLab.
 
 Let us start writing `README.md` using a text editor of your choice and add the following line.
 
@@ -208,23 +208,6 @@ The following optional packages are required to run Inflam's unit tests:
 Here we are making use of Markdown links,
 with some text describing the link within `[]` followed by the link itself within `()`.
 
-One really neat feature - and a common practice - of using many CI infrastructures is that
-we can include the status of running recent tests within our README file.
-Just below the `# Inflam` title on our README.md file,
-add the following (replacing `<your_github_username>` with your own:
-
-~~~
-# Inflam
-![Continuous Integration build in GitHub Actions](https://github.com/<your_github_username>/python-intermediate-inflammation/actions/workflows/main.yml/badge.svg?branch=main)
-...
-~~~
-{: .language-markdown}
-
-This will embed a *badge* (icon) at the top of our page that
-reflects the most recent GitHub Actions build status of your software repository,
-essentially showing whether the tests that were run
-when the last change was made to the `main` branch succeeded or failed.
-
 That's got us started with documenting our code,
 but there are other aspects we should also cover:
 
@@ -368,9 +351,9 @@ $ git push origin main
 
 The software on your `main` branch is now ready for release.
 
-## Tagging a Release in GitHub
+## Tagging a Release in GitLab
 
-There are many ways in which Git and GitHub can help us make a software release from our code.
+There are many ways in which Git and GitLab can help us make a software release from our code.
 One of these is via **tagging**,
 where we attach a human-readable label to a specific commit.
 Let us see what tags we currently have in our repository:
@@ -465,7 +448,7 @@ index 4818abb..5b8e7fd 100644
 ~~~
 {: .output}
 
-So now we have added a tag, we need this reflected in our Github repository.
+So now we have added a tag, we need this reflected in our GitLab project.
 You can push this tag to your remote by doing:
 
 ~~~
@@ -490,7 +473,7 @@ $ git push origin v1.0.0
 {: .callout}
 
 We can now use the more memorable tag to refer to this specific commit.
-Plus, once we have pushed this back up to GitHub,
+Plus, once we have pushed this back up to GitLab,
 it appears as a specific release within our code repository
 which can be downloaded in compressed `.zip` or `.tar.gz` formats.
 Note that these downloads just contain the state of the repository at that commit,
@@ -506,7 +489,7 @@ but tagging with a specific version number makes that just a little bit easier f
 
 We may also wish to make data available to either
 be used with the software or as generated results.
-This may be via GitHub or some other means.
+This may be via GitLab or some other means.
 An important aspect to remember with sharing data on such systems is that
 they may reside in other countries,
 and we must be careful depending on the nature of the data.

_episodes/43-software-release.md

@@ -202,7 +202,7 @@ This is because someone installing our software through a tool like `pip` is onl
 but probably does not intend to contribute to the development of our software
 and does not require development dependencies.
 
-In contrast, if someone downloads our code from GitHub,
+In contrast, if someone downloads our code from GitLab,
 together with our `pyproject.toml`,
 and installs the project that way,
 they will get both our runtime and development dependencies.