differences for PR #8

actions-user · actions-user · commit f0adc08eddac · 2025-11-12T12:30:11.000Z
diff --git a/41-code-review.md b/41-code-review.md
@@ -567,6 +567,27 @@ This tells the author you are happy for them to merge the pull request.
   ![](fig/github-merge-pull-request.png){alt='Merging a pull request in GitHub' .image-with-shadow width="800px"}
 2. Delete the merged branch to reduce the clutter in the repository.
 
+::: callout
+
+### Merge via command line
+
+The `git merge` command provides a way to directly merge branches on your local. In general, when adding changes to the `main` branch, this is not a good practice since it bypasses the code review process. It is a common practice for an open-source project to set its `main` branch protected, meaning pushing directly to `main` branch will fail. Therefore, even you can merge to `main` locally, you will not be able to push the changes to the remote repository.
+
+On the other hand, the `git merge` command can be very useful for keeping your feature branch up to date with the `main` branch. For example, if you are working on a branch `my-feature` and the `main` branch has received new commits (e.g. someone else has merged their pull request), you can do the following to include changes from `main` into your feature branch:
+
+```bash
+# First update your local main branch 
+$ git checkout main
+$ git pull main
+# Then switch back to your feature branch and merge the latest main into it
+$ git checkout my-feature
+$ git merge main
+```
+
+In this way, you can keep your feature branch up to date. You may need to resolve conflicts that arise during this process.
+
+:::
+
 ## Writing Easy-To-Review Code
 
 There are a few things you can do to make it
diff --git a/42-software-reuse.md b/42-software-reuse.md
@@ -344,160 +344,6 @@ Ensure you prioritise and work on the most pressing issues first!
 
 ::::::::::::::::::::::::::::::::::::::::::::::::::
 
-## Merging into `main`
-
-Once you have done these updates,
-commit your changes,
-and if you are doing this work on a feature branch also ensure you merge it into `develop`,
-e.g.:
-
-```bash
-$ git switch develop
-$ git merge my-feature-branch
-```
-
-Finally, once we have fully tested our software
-and are confident it works as expected on `develop`,
-we can merge our `develop` branch into `main`:
-
-```bash
-$ git switch main
-$ git merge develop
-$ git push origin main
-```
-
-The software on your `main` branch is now ready for release.
-
-## Tagging a Release in GitHub
-
-There are many ways in which Git and GitHub 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:
-
-```bash
-$ git tag
-```
-
-Since we have not tagged any commits yet, there is unsurprisingly no output.
-We can create a new tag on the last commit in our `main` branch by doing:
-
-```bash
-$ git tag -a v1.0.0 -m "Version 1.0.0"
-```
-
-So we can now do:
-
-```bash
-$ git tag
-```
-
-```output
-v.1.0.0
-```
-
-And also, for more information:
-
-```bash
-$ git show v1.0.0
-```
-
-You should see something like this:
-
-```output
-tag v1.0.0
-Tagger: <Name> <email>
-Date:   Fri Dec 10 10:22:36 2021 +0000
-
-Version 1.0.0
-
-commit 2df4bfcbfc1429c12f92cecba751fb2d7c1a4e28 (HEAD -> main, tag: v1.0.0, origin/main, origin/develop, origin/HEAD, develop)
-Author: <Name> <email>
-Date:   Fri Dec 10 10:21:24 2021 +0000
-
-	Finalising README.
-
-diff --git a/README.md b/README.md
-index 4818abb..5b8e7fd 100644
---- a/README.md
-+++ b/README.md
-@@ -22,4 +22,33 @@ Flimflam requires the following Python packages:
- The following optional packages are required to run Flimflam's unit tests:
-
- - [pytest](https://docs.pytest.org/en/stable/) - Flimflam's unit tests are written using pytest
--- [pytest-cov](https://pypi.org/project/pytest-cov/) - Adds test coverage stats to unit testing
-\ No newline at end of file
-+- [pytest-cov](https://pypi.org/project/pytest-cov/) - Adds test coverage stats to unit testing
-+
-+## Installation
-+- Clone the repo ``git clone repo``
-+- Check everything runs by running ``python -m pytest`` in the root directory
-+- Hurray 
-+
-+## Contributing
-+- Create an issue [here](https://github.com/Onoddil/python-intermediate-inflammation/issues)
-+  - What works, what does not? You tell me
-+- Randomly edit some code and see if it improves things, then submit a [pull request](https://github.com/Onoddil/python-intermediate-inflammation/pulls)
-+- Just yell at me while I edit the code, pair programmer style!
-+
-+## Getting Help
-+- Nice try
-+
-+## Credits
-+- Directed by Michael Bay
-+
-+## Citation
-+Please cite [J. F. W. Herschel, 1829, MmRAS, 3, 177](https://ui.adsabs.harvard.edu/abs/1829MmRAS...3..177H/abstract) if you used this work in your day-to-day life.
-+Please cite [C. Herschel, 1787, RSPT, 77, 1](https://ui.adsabs.harvard.edu/abs/1787RSPT...77....1H/abstract) if you actually use this for scientific work.
-+
-+## License
-+This source code is protected under international copyright law.  All rights
-+reserved and protected by the copyright holders.
-+This file is confidential and only available to authorized individuals with the
-+permission of the copyright holders.  If you encounter this file and do not have
-+permission, please contact the copyright holders and delete this file.
-\ No newline at end of file
-```
-
-So now we have added a tag, we need this reflected in our Github repository.
-You can push this tag to your remote by doing:
-
-```bash
-$ git push origin v1.0.0
-```
-
-:::::::::::::::::::::::::::::::::::::::::  callout
-
-## What is a Version Number Anyway?
-
-Software version numbers are everywhere,
-and there are many different ways to do it.
-A popular one to consider is [**Semantic Versioning**](https://semver.org/),
-where a given version number uses the format MAJOR.MINOR.PATCH.
-You increment the:
-
-- MAJOR version when you make incompatible API changes
-- MINOR version when you add functionality in a backwards compatible manner
-- PATCH version when you make backwards compatible bug fixes
-
-You can also add a hyphen followed by characters to denote a pre-release version,
-e.g. 1.0.0-alpha1 (first alpha release) or 1.2.3-beta4 (fourth beta release)
-
-
-::::::::::::::::::::::::::::::::::::::::::::::::::
-
-We can now use the more memorable tag to refer to this specific commit.
-Plus, once we have pushed this back up to GitHub,
-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,
-and not its entire history.
-
-Using features like tagging allows us to highlight commits that are particularly important,
-which is very useful for *reproducibility* purposes.
-We can (and should) refer to specific commits for software in
-academic papers that make use of results from software,
-but tagging with a specific version number makes that just a little bit easier for humans.
 
 ## Conforming to Data Policy and Regulation
 
diff --git a/43-software-release.md b/43-software-release.md
@@ -19,6 +19,137 @@ exercises: 20
 
 ::::::::::::::::::::::::::::::::::::::::::::::::::
 
+## Tagging a Release in GitHub
+
+There are many ways in which Git and GitHub 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:
+
+```bash
+$ git tag
+```
+
+Since we have not tagged any commits yet, there is unsurprisingly no output.
+We can create a new tag on the last commit in our `main` branch by doing:
+
+```bash
+$ git tag -a v1.0.0 -m "Version 1.0.0"
+```
+
+So we can now do:
+
+```bash
+$ git tag
+```
+
+```output
+v.1.0.0
+```
+
+And also, for more information:
+
+```bash
+$ git show v1.0.0
+```
+
+You should see something like this:
+
+```output
+tag v1.0.0
+Tagger: <Name> <email>
+Date:   Fri Dec 10 10:22:36 2021 +0000
+
+Version 1.0.0
+
+commit 2df4bfcbfc1429c12f92cecba751fb2d7c1a4e28 (HEAD -> main, tag: v1.0.0, origin/main, origin/develop, origin/HEAD, develop)
+Author: <Name> <email>
+Date:   Fri Dec 10 10:21:24 2021 +0000
+
+	Finalising README.
+
+diff --git a/README.md b/README.md
+index 4818abb..5b8e7fd 100644
+--- a/README.md
++++ b/README.md
+@@ -22,4 +22,33 @@ Flimflam requires the following Python packages:
+ The following optional packages are required to run Flimflam's unit tests:
+
+ - [pytest](https://docs.pytest.org/en/stable/) - Flimflam's unit tests are written using pytest
+-- [pytest-cov](https://pypi.org/project/pytest-cov/) - Adds test coverage stats to unit testing
+\ No newline at end of file
++- [pytest-cov](https://pypi.org/project/pytest-cov/) - Adds test coverage stats to unit testing
++
++## Installation
++- Clone the repo ``git clone repo``
++- Check everything runs by running ``python -m pytest`` in the root directory
++- Hurray 
++
++## Contributing
++- Create an issue [here](https://github.com/Onoddil/python-intermediate-inflammation/issues)
++  - What works, what does not? You tell me
++- Randomly edit some code and see if it improves things, then submit a [pull request](https://github.com/Onoddil/python-intermediate-inflammation/pulls)
++- Just yell at me while I edit the code, pair programmer style!
++
++## Getting Help
++- Nice try
++
++## Credits
++- Directed by Michael Bay
++
++## Citation
++Please cite [J. F. W. Herschel, 1829, MmRAS, 3, 177](https://ui.adsabs.harvard.edu/abs/1829MmRAS...3..177H/abstract) if you used this work in your day-to-day life.
++Please cite [C. Herschel, 1787, RSPT, 77, 1](https://ui.adsabs.harvard.edu/abs/1787RSPT...77....1H/abstract) if you actually use this for scientific work.
++
++## License
++This source code is protected under international copyright law.  All rights
++reserved and protected by the copyright holders.
++This file is confidential and only available to authorized individuals with the
++permission of the copyright holders.  If you encounter this file and do not have
++permission, please contact the copyright holders and delete this file.
+\ No newline at end of file
+```
+
+So now we have added a tag, we need this reflected in our Github repository.
+You can push this tag to your remote by doing:
+
+```bash
+$ git push origin v1.0.0
+```
+
+:::::::::::::::::::::::::::::::::::::::::  callout
+
+## What is a Version Number Anyway?
+
+Software version numbers are everywhere,
+and there are many different ways to do it.
+A popular one to consider is [**Semantic Versioning**](https://semver.org/),
+where a given version number uses the format MAJOR.MINOR.PATCH.
+You increment the:
+
+- MAJOR version when you make incompatible API changes
+- MINOR version when you add functionality in a backwards compatible manner
+- PATCH version when you make backwards compatible bug fixes
+
+You can also add a hyphen followed by characters to denote a pre-release version,
+e.g. 1.0.0-alpha1 (first alpha release) or 1.2.3-beta4 (fourth beta release)
+
+
+::::::::::::::::::::::::::::::::::::::::::::::::::
+
+We can now use the more memorable tag to refer to this specific commit.
+Plus, once we have pushed this back up to GitHub,
+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,
+and not its entire history.
+
+Using features like tagging allows us to highlight commits that are particularly important,
+which is very useful for *reproducibility* purposes.
+We can (and should) refer to specific commits for software in
+academic papers that make use of results from software,
+but tagging with a specific version number makes that just a little bit easier for humans.
+
 ## Why Package our Software?
 
 We have now got our software ready to release -
diff --git a/md5sum.txt b/md5sum.txt
@@ -30,9 +30,9 @@
 "episodes/34-code-refactoring.md" "ecfc3e80e4e9a453a0a10069d0d4e894" "site/built/34-code-refactoring.md" "2025-06-19"
 "episodes/35-software-architecture-revisited.md" "8f92fb912d61d3aded15f51020699a14" "site/built/35-software-architecture-revisited.md" "2025-06-19"
 "episodes/40-section4-intro.md" "d8aa3c327409db1b14826b7619287c45" "site/built/40-section4-intro.md" "2025-06-19"
-"episodes/41-code-review.md" "e86600e42548b6d652fb9b43450222fc" "site/built/41-code-review.md" "2025-06-25"
-"episodes/42-software-reuse.md" "d97b8a23401a52bfb6dc5e564981fcf2" "site/built/42-software-reuse.md" "2025-06-19"
-"episodes/43-software-release.md" "25bfda77cec4fea12479541c71317dc1" "site/built/43-software-release.md" "2025-10-24"
+"episodes/41-code-review.md" "7d2da980b93fb9e5f21a090174528e7a" "site/built/41-code-review.md" "2025-11-12"
+"episodes/42-software-reuse.md" "9465c27f2e2d41abae70b52764034edf" "site/built/42-software-reuse.md" "2025-11-12"
+"episodes/43-software-release.md" "52e6254f19a85faadd235bde7844e47b" "site/built/43-software-release.md" "2025-11-12"
 "episodes/50-section5-intro.md" "85de74adcd13ba9e8a6df600a17b9ddc" "site/built/50-section5-intro.md" "2025-06-19"
 "episodes/51-managing-software.md" "666be3cf81dab6bb120f649c65bd64c1" "site/built/51-managing-software.md" "2025-06-19"
 "episodes/52-assessing-software-suitability-improvement.md" "f13f4136753468a43d3c2364fa6aabd4" "site/built/52-assessing-software-suitability-improvement.md" "2025-10-20"
