git for Scientific Software Development

Jack Atkinson

Principal Research Software Engineer
ICCS - University of Cambridge

Mikolaj Kowalski

Senior Research Software Engineer
ICCS - University of Cambridge

2026-07-16

Precursors

Slides and Materials

To access links or follow on your own device these slides can be found at:
jatkinson1000.github.io/git-for-science


All materials are available at:

Licensing

Except where otherwise noted, these presentation materials are licensed under the Creative Commons Attribution-NonCommercial 4.0 International (CC BY-NC 4.0) License.

Vectors and icons by SVG Repo used under CC0(1.0)

Precursors

  • Be nice (Python code of conduct)
  • Ask questions whenever they arise.
    • Someone else is probably wondering the same thing.
    • For troubleshooting please write a message in the zoom chat and someone will assist you in a thread
    • For more general queries please raise a hand.
  • I will make mistakes.
    • Not all of them will be intentional.

Learning Objectives

  • Recap the basic git commands
  • Understand key components of git repositories to aid in collaboration


  • Link git version control to online tools of GitHub/GitLab
  • Learn how to use git and GitHub/GitLab to better manage development and collaboration
    • branches
    • issues
    • merge/pull requests
    • code review

Structure & Premise

  • This workshop has teaching interwoven with practical exercises
  • We will be fork and clone a simple git repository, improving it throughout the course
  • After learning new concepts we will immediately put them into practice with a practical exercise.

I suggest you have open:

  • A text editor or IDE
  • A terminal window
  • A browser window

Installation and setup

Git comes preinstalled on most Linux distributions and macOS.
You can check it is on your system by running which git.


If you are on Windows, or do not have git, check the git docs1 or the GitHub guide to installing git. https://github.com/git-guides/install-git


For this workshop we will assume that a repository you wish to work on already exists online online (on GitLab, GitHub etc.).

Setting up a new git repository is beyond the scope of this talk but involves using the git --init command.


git 101

How does git work?

A mental model:

  • Each time you commit work git stores it as a diff.
    • This shows specific lines of a file and how they changed (+/-).
    • This is what you see with the git diff command.
  • diffs are stored in a tree.
    • By applying each diff one at a time we can reconstruct files.
    • We do not need to do this in order
      see cherry-picking and merge conflicts…

git Geography

Locations

  • Local
    • Workspace
    • Staging area or index
    • Local repo
    • Stash
  • Remote
    • Remote repo

Tip

These (and more) can be explored in Andrew Peterson’s Interactive git cheat sheet

The basic commands

  • git clone <repo> [<dir>]
    • Clone a repository into a new directory
  • git status
    • Check the state of the local workspace
  • git add <filepath>
    • Update the index with any changes
  • git commit
    • git commit -m <message>
    • Commit changes in the index to (local) record
  • git push <remote> <branch>
    • Send your locally committed changes to the remote repo
  • git pull <remote> <branch>
    • Get changes from the remote repo locally

Branches

Branches help in both individual and collaborative work, e.g.

  • Modifying the same files as someone else?
  • Working on different features in parallel?

    %%{init: {'theme': 'base',
              'gitGraph': {'rotateCommitLabel': true},
              'themeVariables': {
                  'commitLabelBackground': '#bbbbbb',
                  'commitLabelColor': '#ffffff'
    } } }%%
    gitGraph
       commit id: "4-ff6b"
       commit id: "0-fd7f"
       commit id: "fea 1.a"
       commit id: "fea 1.b"
       commit id: "fea 1.c"
       commit id: "fea 1.d"
       commit id: "5-af6f"

Conduct development in branches and merged into main when completed:

    %%{init: {'theme': 'base',
              'gitGraph': {'rotateCommitLabel': true},
              'themeVariables': {
                  'commitLabelBackground': '#bbbbbb',
                  'commitLabelColor': '#ffffff'
    } } }%%
    gitGraph
       commit id: "4-ff6b"
       commit id: "0-fd7f"
       branch feature_1
       commit id: "fea 1.a"
       commit id: "fea 1.b"
       checkout main
       branch feature_2
       commit id: "fea 2.a"
       checkout feature_1
       commit id: "fea 1.c"
       checkout main
       merge feature_1
       checkout feature_2
       commit id: "fea 2.b"
       checkout main
       merge feature_2
       commit id: "5-af6f"
       commit id: "1-ad4e"

  • git branch <branchname>
    • Creates new branch branchname from current point
  • git checkout <branchname>
    • move workspace to branchname
  • git merge <branchname>
    • Tie branchname into the current checked out branch with a merge commit.

Workshop Premise

You are doing some work on pendula and your colleague says they have written some code that solves the equations and they can share with you.
This is made easy by the fact that it is on git!
Let’s see how we get on…


The code can be found in the workshop repository:

Exercise

Obtain a copy of the repository by first forking it on GitHub and then cloning your local copy using from the online remote using git clone.

Tip

If you are not the owner or a direct collaborator on a repository then forking is the standard way to collaborate. It creates a copy you can edit, whilst retaining a link to the original code to allow contribution back.
This course will explore how to work in both ways.


Take a look around the software and code, how useful is it?1


You can fork by clicking the following link:
/jatkinson1000/git-for-science/fork

Repository Files

README

  • A file in the main directory of your repository.
  • The entry point for new users.
  • Helps to ensure your code:
    • is accessible
    • is used properly
    • has longevity
  • Today encouraged to be written in Markdown as README.md.

README - examples

README

Essential:

  • Name
  • Short summary
  • Install instructions
  • Usage/getting-started instructions
  • Information about contributing
  • Authors and Acknowledgment
  • License information

Nice to have:

  • References to key papers/materials
  • Badges
  • Examples
  • Link to docs
  • List of users
  • FAQ
  • See readme.so/ for a longer list

makeareadme.com and readme.so are great tools to help.

Add as soon as you can in a project and update as you go along.

README - good examples

Exercise - README

How can we improve the README in the pyndulum code?

Create a feature branch and edit the README.md file to improve it. In-particular think about:

  • A description of what the code is
  • How it can be installed
  • How to use it or get started
  • Information about the authors and how to contribute

Add and commit your changes.

If you are working in a fork then push to see these changes reflected as a branch on the online remote repository.

Extension Exercise - README

I have made my additions to the README in my original repository.


Since you have made a fork you can get these updates directly on GitHub by “synchronising” your fork.


After doing this check out the main branch locally and pull to get the changes in your local working directory.

Licenses

All public codes should have a license attached!

  • As a LICENSE file in the main directory
    • Recommended to to choose an OSI-approved license without modification.
  • Protects ownership and limits liability
  • Enables collaboration
  • Clarifies what can be done with the code and its derivatives
    • Public Domain ↔︎ Permissive ↔︎ Copyleft
    • The options may depend on your organisation and/or funder.

See choosealicense.com and the OSI list of licenses for more information.

GitHub and GitLab contain helpers to easily create popular licenses.

Adding a License - GitLab

1) From the main repo select the “+” dropdown menu and “New file”.

2) In the filename type “LICENSE” and GitLab will detect and offer you a dropdown to choose a LICENSE template.

3) Once you have chosen you can “Commit Changes” to add the file. It will appear as a LICENSE file at the top of the repository and will be detected by GitLab in the right hand side metadata.

Adding a License - GitHub

From the main repo select “Add file” and “+ Create new file”.

In the filename type “LICENSE” and GitHub will detect and offer you the option to choose a LICENSE template.

Adding a License - GitHub

Select your desired license and follow the instructions to apply it to your repository. Once complete it will appear as a LICENSE file at the top of the repository and will be detected by GitHub in the right hand side metadata.

Exercise - License

Add a license to our pyndulum code.


We will use the online helper features of GitHub or GitLab to choose and add a License.


Once you have done this don’t forget to run:

git pull <repo> <branch>

from your local copy to get these changes locally before you make further updates.

.gitignore

It is a good idea to add a .gitignore file to your projects:

  • A list of file patterns that will be skipped over by git.
  • Makes it easier for us to see through to what is important.
  • Used for:
    • junk that shouldn’t be in there - the infamous .DS_store
    • build files - mycode.o, mymodule.mod, out.a etc.
    • local environments - .venv/
    • large files - 50_year_run.nc or my_thesis.pdf etc.
    • keeping sensitive information out of public1

Generating a gitignore

  • Again, GitHub and GitLab contain helpers and templates to create .gitignore.

    • Add a file and this time enter “.gitignore” to get templates.
  • gitignore.io also provides support for generating multi-language .gitignores.

  • You can always edit the file later to add more things to it.


Tip

While it can be tempting to use git add -a it should be avoided to prevent detritus and unclear commits.
A better alternative is git add -u.

Exercise - .gitignore

Add a .gitignore to the pyndulum code?


We will use the online helper features of GitHub or GitLab to set up a basic .gitignore file for a Python code.


Again, once you have done this don’t forget to run:

git pull <repo> <branch>

from your local copy to get these changes locally before you make further updates.

Git Workflow

Issues

Both GitHub and GitLab have methods for tracking issues.

These are useful for organising work.

  • managing separate tasks
  • logging problems/tasks as they arise
  • tracking and scheduling development


Note

Issues are part of GitHub/GitLab, NOT the git repository.
They will not be kept if you move the project elsewhere and do not appear on your local system.

GitHub

GitLab

What goes in an Issue?

  • Issues could be for bug-report or development
  • A clear statement of the problem or proposed work
  • Steps for others to reproduce the problem
  • Links to any relevant resources
  • Previously tried solutions
  • Relevant tags on the repository

Note

Projects may use a template for issues guiding what they want to see.

Example issues:

Exercise - Issues

It would enhance the pyndulum code if we added functions to calculate:

  • pendulum total energy, and
  • pendulum length from desired period.


We will open issues for these on the online repository.

I will open one for pendulum energy, but you should open one for pendulum length.


Issues and Forks

By default issues are off for forks, so you should open the issue on my copy of the repository on GitLab or GitHub.

Exercise - Adding Equations

Having opened those issues let’s now add functions to calculate

  • pendulum energy, and
  • pendulum length from desired period.


I will create a local branch and add the energy equation to pendulum_equations.py, add, commit, and push those changes.


You should create your own branch from main and add the length equation to pendulum_equations.py. Make sure you add and commit your changes, and then push them to a branch on your remote.

Aside - Commit Messages

Merge/Pull Requests

How to get your new code back to the main source!

  • Another feature of GitHub/GitLab.1

  • A friendlier, graphical way of merging branches

  • Can be linked to GitHub/GitLab issues

  • A method of tracking progress

    • can be opened after the first push
    • a place for collaborative discussion.

Examples:

Merge strategies

There are a few different ways to merge branches: “merge”, “rebase”, “squash”.
Exploring these is beyond the scope of today’s course, but we’d be happy to discuss further afterwards.

Merge/Pull Requests

When opening a request you should include:

  • A description of what you have done
  • Any points to be particularly aware of
  • Checkboxes for required/ongoing tasks

We will demonstrate opening:

  • an internal pull request with the energy equation, and
  • an external pull request with the length equation.

Exercise - Merge/Pull requests

From the length equation branch you pushed in the previous exercise, open a pull request either:

  • into the main branch of your fork, or
  • back to the main branch of my repository.

Use additional features of GitHub/GitLab:

  • write a clear description of the contribution,
  • use keywords to tie back to the issue you opened e.g. “closes #6”,
  • add the “new equation” label to categorise the work,
  • assign yourself as the author.

Aside - Commit Frequency

There are differing thoughts on commit frequency and style. I suggest:

  • Synoptic Scale: Project or Meta-issues
  • Mesoscale: Pull requests
  • Microscale: Commits

Some useful examples:

  • CAM-ML #23 - Adding number concentration calculations
  • CAM-ML #32 - restoring a previously removed variable
    We can look directly at 8bdb319 to see what needs doing.
  • FTorch #230 - Adding optimizers
    A little long, but shows the development process and discussions.
  • TCTrack #69 - Refactoring code structure
    A big refactor, but we break up into logical chunks should one have an issue.

Code Review

Code review is the process of having someone else read, run(?) and provide feedback.

Code review is not:

  • just for ‘real’ software
  • a chance to feel bad about your code

Code review is:

  • chance to reflect on what you wrote,
  • chance to spot bugs - we all make them!
  • testing that someone else can understand your code,
  • guarding against laziness,
  • a method to improve quality reusability,
  • chance to learn.

Code Review

Again, GitHub and GitLab have nice infrastructure to make this an effective and visual process.

Anyone can conduct a code review on a public repository.
If working alone ask colleagues for help and return the favour.


Do:

  • remember who the person you are reviewing is
  • explain your reasons for requests
  • praise good code, not just point out errors

Do not:

  • impose preferences
  • nitpick excessively

Exercise - Code Review

We will work through the length equation pull requests and perform code reviews before merging the work.


Work in pairs to review one-another’s code. If anyone in the audience opened a pull request back to my repository and would like to volunteer we can review your code together!

Closing

Summary

git is not just a series of backups, it is a project management system.


  • Improve your repositories:
    • README.md
    • LICENSE
    • .gitignore
  • Use branches:
    • Separate workflows
    • Organise project
  • Make full use of GitLab/GitHub features:
    • Helper tools
    • Issues
    • Pull Requests
    • Code review:
      • Learn, spot bugs, improve re-useability

Beyond today

Today has introduced the basics for good collaborative work and project management using git and GitHub/GitLab.

Further topics to explore beyond the scope of today include:

  • Project Boards for project management,
  • Merge commit, squash, and rebase options for merging,
  • Advanced git practices from the intermediate git course for clean commit histories,
  • git worktrees to help organise working on branches in parallel,
  • Continuous Integration workflows,
  • pre-commit hooks

Where can I learn more?

  • GitButler’s 2024 FOSDEM talk “so you think you know git?”:

Thanks

References

Plus other links throughout the slides.