Instructor Notes

Using a software tool to handle the versions of your project files lets you focus on the more interesting/innovative aspects of your project.

  • Version control’s advantages
    • It’s easy to set up
    • Every copy of a Git repository is a full backup of a project and its history
    • A few easy-to-remember commands are all you need for most day-to-day version control tasks
    • Hosting services like Codeberg provide a web-based collaboration service
  • Two main concepts
    • commit: a recorded set of changes in your project’s files
    • repository: the history of all your project’s commits
  • Why use Codeberg?
    • No need for a server: easy to set up
    • Non-profit, community-run and hosted in the EU, built on free software (Forgejo)
    • Everything learners practise transfers directly to GitHub, GitLab and institutional instances, which their colleagues may already be using

Overall

Version control might be the most important topic we teach, but Git is definitely the most complicated tool. However, Git is the basis of nearly all open software and research repository platforms (Codeberg, GitHub, GitLab, …), so the time and effort required to teach fundamental Git is justified and worthwhile.

Because of this complexity, we don’t teach novice learners about many interesting topics, such as branching, hashes, and commit objects.

Instead we try to convince them that version control is useful for researchers working in teams or not, because it is

  • a better way to “undo” changes,
  • a better way to collaborate than mailing files back and forth, and
  • a better way to share your code and other scientific work with the world.

Troubleshooting Common Problems

  • When using an outdated version of Windows OpenSSH, learners cannot set up the SSH connection to Codeberg.

    • Try updating their version of OpenSSH version.

Making a handout

To make a handout for this lesson, adapt/print from the Reference page.

Teaching Notes

  • Utility for “splitting” your shell so that recent commands remain in view: Software Carpentry Shell Split Window.

  • Make sure the network is working before starting this lesson.

  • Drawings are particularly useful in this lesson: if you have a whiteboard, use it to visualise and describe the fork-and-pull-request workflow. The Codeberg documentation on pull requests and Git flow can serve as inspiration.

  • Version control is usually not the first subject in a workshop, so get learners to create a Codeberg account after the session before. Remind learners that the username and email they use for Codeberg (and setup during Git configuration) will be viewable to the public by default. However, there are many reasons why a learner may not want their personal information viewable. Codeberg lets them hide their email address on their profile and use a private noreply address for commits (see the account settings).

  • Codeberg Pages only publishes public repositories and needs a webhook (episode “Codeberg Pages”). The most common problems are a wrong target URL (it must end with /hello-world/) or a missing pages branch filter. Check “Recent deliveries” on the webhook page together with the learner.

  • Codeberg Pages does not render Markdown. If learners ask why the original Library Carpentry lesson uses index.md: GitHub Pages runs Jekyll, Codeberg Pages only serves files.

  • It is likely that learners will run into issues when merging files due to whitespace differences. For example, a text editor might automatically add a newline to the last line of a file, causing an unexpected difference. Conflicts can also arise due to Windows using different line endings from other operating systems. Take a moment to explain these issues, since learners will almost certainly trip over them again. The Pro Git book explains how to configure Git to handle line endings with the core.autocrlf setting.

  • We don’t use a Git GUI in this lesson because we haven’t found one that installs easily and runs reliably on the three major operating systems, and because we want learners to understand what commands are being run. That said, instructors should demo a GUI on their desktop at some point during this lesson and point learners at the Git website’s list of available GUIs.

  • Instructors should show learners graphical diff/merge tools like DiffMerge.

  • When appropriate, explain that we teach Git rather than CVS, Subversion, or Mercurial primarily because of its wide adoption and the many platforms built on it: CVS and Subversion are now seen as legacy systems, and Mercurial isn’t nearly as widely used in the sciences right now.

  • Further resources: