Update git course with exercises and some more advanced material by fcooper8472 · Pull Request #268 · UNIVERSE-HPC/course-material

fcooper8472 · 2026-07-15T12:42:36Z

Add:

More advanced material (rebase, bisect etc)
Add exercises with solutions (previously none in this course)
Add "key points" sections for each lesson

The main additions are migrating the remaining content from this course:
https://github.com/OxfordRSE/git-github-course

The more advanced material is marked as such, so minor content changes for someone just starting with Git, but some stretch material for people more familiar.

The other major change is adding some exercises. They're fairly trivial, but hopefully will help improve engagement.

(There are a large number of whitespace changes, Windows to Unix endings... @alasdairwilson dunno if it's worth a one-time normalisation of line endings and some instrumentation to catch this on PRs in future, to avoid future large diffs?)

martinjrobins

thanks @fcooper8472, changes look great, a few suggestions below

martinjrobins · 2026-07-20T09:20:08Z

+![GitHub Desktop](fig/01-background/desktop.png)
+
+Fundamentally, though, these are all just 'wrappers' around the command line version of Git.
+If you understand what they're doing under the hood, you can easily switch between versions. You can, for example, manage your code on Iridis using command-line git and GitHub Desktop on your desktop workstation.


what is Iridis?

looks like southamptons supercsomputer

martinjrobins · 2026-07-20T09:20:40Z

+
+:::callout
+
+## Git GUI Integrations


Suggested change

## Git GUI Integrations

## Git IDE Integrations

martinjrobins · 2026-07-20T09:21:51Z

+A colleague is about to put their research project into Git. Which of the following would you recommend they track, and which would you leave out?
+
+1. Their analysis scripts (`analysis.py`)
+2. A 2 GB raw data file downloaded from a public archive


you don't discuss anywhere above what can and can't be tracked

martinjrobins · 2026-07-20T10:47:20Z

+...
+```
+
+By default, `restore` replaces the file with the version of it in the _staging area_. If you haven't used `git add`, that should be the same as the version in the last commit. But what if we already used `git add` on our incorrect version of a file, or we broke the file more than one commit ago?


one thing I found confusing looking at the git documentation was that the staging area is usually called the "index", not sure if you mention that anywhere

martinjrobins · 2026-07-20T10:50:55Z

+Consider a situation where all your code is in one file,
+and you fixed a bug in one section but accidentally introduced one elsewhere.
+
+You can't just roll back to fix one bug without un-fixing the other.


well, you can fairly easily if you are in an IDE. or (more difficult) you can use the interactive mode of git to do it line by line

martinjrobins · 2026-07-20T10:53:14Z

+:::callout
+If the change you're reverting overlaps with later edits, Git may not be able to
+work out how to undo it automatically and will report a **conflict**. If that
+happens, resolve it by hand exactly as you did for merge conflicts in the previous


I don't remember if merge conflicts were covered?

in 06-remote.md, so after this.

martinjrobins · 2026-07-20T10:58:59Z

+The remaining modules in this course are optional and marked _(Advanced)_. Come
+back to them whenever you meet the problem each one solves:
+
+- **Rebasing and Squashing**: produce a clean, linear history.


put links to these modules

martinjrobins · 2026-07-20T11:00:00Z

+them, rebasing will rewrite commits that others already have - and things will
+get badly tangled.
+
+Only rebase commits that are still **private** to your local repository. If in


or in a private branch on the remote

I think in general this callout both undersells rebase, cause it is useful even on shared work, and also

“Never rebase anything already pushed” obscures the actual danger. Rebasing creates new commit identities; if someone has fetched or based work on the original commits, their history will diverge and they must reconcile it after the rewritten branch is force-pushed.

But rebasing pushed feature, draft-PR, backport branches is routine when ownership is clear and collaborators are coordinated. Could this callout instead say: Do not rebase commits that other people may be using without coordinating with them first?

alasdairwilson

I sliced the end off one of my fingers :( so I'm making a lot of typos, typing a finger down on my left hand.

So apologies for the unreadbale garbage.

Otherwise this looks good to me mostly..

I've made some suggestions though.

alasdairwilson · 2026-07-20T11:27:46Z

+## Setting work aside with `git stash`
+
+Before you can `git pull`, you need to have committed any changes you have made.
+But what if you want to pull, and you're **not ready to commit**? You can
+temporarily "put aside" your uncommitted changes with `git stash`:
+
+```bash
+git stash
+git pull
+```
+
+Stashing takes your uncommitted changes off the working directory and saves them
+away, leaving your repository clean so the pull can proceed. When you're ready,
+bring your changes back with:
+
+```bash
+git stash pop
+```
+
+(`git stash apply` does the same but keeps a copy in the stash list; `git stash
+list` shows what you have stashed.) The stash is a great way to save your working
+state in a pinch - for example when you need to quickly switch branches to fix
+something urgent.


Think this should include that git stash only stashed changes in tracked files, so it will leave untracked files.

Could also include "git stash -u" for stashing untracked files.

alasdairwilson · 2026-07-20T11:28:25Z

+:::callout
+If the change you're reverting overlaps with later edits, Git may not be able to
+work out how to undo it automatically and will report a **conflict**. If that
+happens, resolve it by hand exactly as you did for merge conflicts in the previous


in 06-remote.md, so after this.

alasdairwilson · 2026-07-20T12:01:15Z

+
+## Referencing remotes
+
+When you run `git fetch`, Git downloads the latest state of a remote **without**


because this is right after saying git remote add upstream then perhaps it is not transparent enough that this will only fetch origin and not upstream (add -all or specifically call out git fetch upstream)

alasdairwilson · 2026-07-20T12:03:02Z

+For example, `git clean -fdX` clears out everything your `.gitignore` matches
+(such as generated `*.pdf` or `__pycache__` files) while leaving new source files
+you haven't committed yet untouched.


I think this perhaps is a bad command to have as ane xample, someone is likely to run it and lose files? could you do the preview version. -ndX? and have the callout indicate that omitting the -n from git clean is dangerous

alasdairwilson · 2026-07-20T12:29:35Z

+A `git merge` is only one of two ways to combine someone else's work (or the work
+on another branch) with your own. The other is called a **rebase**.
+
+- In a **merge**, Git adds a new _merge commit_ that brings the two branches
+  together. **Both histories are kept**, and the graph shows a divergence
+  followed by a convergence.


I felt that this misrepresented git merge (which as you explain later can fast forward)

Suggested change

A `git merge` is only one of two ways to combine someone else's work (or the work

on another branch) with your own. The other is called a **rebase**.

- In a **merge**, Git adds a new _merge commit_ that brings the two branches

together. **Both histories are kept**, and the graph shows a divergence

followed by a convergence.

Merging and rebasing are two common ways to combine work from different branches:

- When **diverged branches are merged**, Git preserves their existing commits and normally creates a new _merge commit_ that joins the two histories.

alasdairwilson · 2026-07-20T13:05:55Z

+```bash
+python -m pytest tests/test_conversion.py   # passes?
+git bisect good
+
+python -m pytest tests/test_conversion.py   # fails?
+git bisect bad
+```


I think it is better to explain this like:

Suggested change

```bash

python -m pytest tests/test_conversion.py # passes?

git bisect good

python -m pytest tests/test_conversion.py # fails?

git bisect bad

```

```bash

python -m pytest tests/test_conversion.py

```

If it passes, mark the current commit as good:

```bash

git bisect good

```

Or, if it fails, mark the current commit as bad:

```bash

git bisect bad

```

alasdairwilson · 2026-07-20T13:09:50Z

+:::callout{variant="tip"}
+This is a strong argument for keeping a good test suite: with automated tests,
+finding _when_ a regression was introduced becomes a single command.
+:::


I mean it isnt a single command, requires setup and repeated commands but shall we say...

Suggested change

:::callout{variant="tip"}

This is a strong argument for keeping a good test suite: with automated tests,

finding _when_ a regression was introduced becomes a single command.

:::

:::callout{variant="tip"}

This is a strong argument for keeping a good test suite: with automated tests and bisect,

finding _when_ a regression was introduced becomes a much simpler process.

:::

alasdairwilson · 2026-07-20T13:14:49Z

+If `..` is used with nothing after it, `HEAD` is assumed, so `v1.0..` means
+"everything after v1.0, up to now".


Since "everything after v1.0" implies a linear history, IK thought the following was better

Suggested change

If `..` is used with nothing after it, `HEAD` is assumed, so `v1.0..` means

"everything after v1.0, up to now".

If `..` is used with nothing after it, `HEAD` is assumed.

This lists commits reachable from HEAD that are not part of v1.0.

In a simple linear history, these are the commits made since the release.

alasdairwilson · 2026-07-20T13:18:27Z

+
+| Centralised (cvs, svn)             | Distributed (git, mercurial)          |
+| ---------------------------------- | ------------------------------------- |
+| Server holds the history           | Every clone has the _full_ history    |


alasdairwilson · 2026-07-20T13:19:46Z

+Older version control systems (like CVS and Subversion) were **centralised**: the
+history lived only on a server, and almost every operation required an internet
+connection.


I think this perhaps minimsed these toosl, both that they needed internet,might be a locla server, and that every opoeration needed the server.

fcooper8472 added 2 commits July 15, 2026 14:05

Migrate remaining conepts from OxRSE git+github course

0d185c3

Add exercises and key points

a455043

fcooper8472 requested review from alasdairwilson, martinjrobins and steve-crouch July 15, 2026 12:42

fcooper8472 linked an issue Jul 15, 2026 that may be closed by this pull request

Update git course with intermediate material #267

Open

fcooper8472 mentioned this pull request Jul 15, 2026

Refresh version control slides OxfordRSE/training-slides-core#59

Closed

martinjrobins approved these changes Jul 20, 2026

View reviewed changes

alasdairwilson reviewed Jul 20, 2026

View reviewed changes


		## Referencing remotes

		When you run `git fetch`, Git downloads the latest state of a remote without

		If `..` is used with nothing after it, `HEAD` is assumed, so `v1.0..` means
		"everything after v1.0, up to now".

-If `..` is used with nothing after it, `HEAD` is assumed, so `v1.0..` means
-"everything after v1.0, up to now".
+If `..` is used with nothing after it, `HEAD` is assumed.
+This lists commits reachable from HEAD that are not part of v1.0.
+In a simple linear history, these are the commits made since the release.

	\| Server holds the history \| Every clone has the _full_ history \|
	\| Server holds the history \| A normal clone has the _full_ history \|

Uh oh!

Conversation

fcooper8472 commented Jul 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

martinjrobins left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alasdairwilson left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alasdairwilson Jul 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

fcooper8472 commented Jul 15, 2026 •

edited

Loading

alasdairwilson left a comment •

edited

Loading

alasdairwilson Jul 20, 2026 •

edited

Loading