Git Introduction

This is the website/repository for the Git introduction that I gave at TU Dresden on 2023-08-16.

Here are the most important links:
  • Visit the repository.
  • Download the slides
    They are autogenerated by a GitLab CI job on every push; see here.
    here:
  • View a transcript of the interactive part of the talk.
  • The website for the introduction (which just mirrors the readme).

Cloning§

The repository employs git submodules
Another great thing to learn!
in order to bring the beamer class and the style file into scope. This means that it needs to be cloned with the --recurse-submodules (or --recursive) flag: 
# If you have set up SSH keys
$ git clone --recurse-submodules \
    git@gitlab.mn.tu-dresden.de:s0428072/git-introduction.git

# If you don't
$ git clone --recurse-submodules \
    https://gitlab.mn.tu-dresden.de/s0428072/git-introduction.git

Building§

Use pdflatex or latexmk to build; e.g., 
$ latexmk -pdf main.tex

Exercise§

As an exercise to apply some of the things we talked about, perform the following tasks in a private repository. If it’s helpful, document which Git command you have used and why.

  • Create a new directory on your computer, and initialize a new Git repository inside.

  • Put a text file of some sort into the repository, add it to the files tracked by Git, and commit your changes to the repository, using a meaningful commit message.

  • Check that your commit was successful by reading the log file, and take a look at the status of your working directory.

  • Change something in the text file, add, and commit those changes.
    Remember those meaningful commit messages!
    Assume you have made a mistake, and amend your commit.

  • Edit the file a second time, but stash your changes away to keep them save for using them at some later point.

On the universities GitLab, find the “Projects” tab and press the “New Project” button. Enter a project name and set the visibility to something of your liking. Do not initialise the project in any way (say, with a readme file).

Follow the instructions under “Git global setup” and “Existing Git repository” to get your project on GitLab. Note that there are also options for completely new projects or existing (non-Git) directories.

  • Use the URL on the project page to create another copy of your repository on your computer. Let’s call this repo2, while the original repository is repo1.

  • Change something in the file in repo2, add, commit, and push it to GitLab.

  • Change a different line in repo1. Pulling the newest version from GitLab should silently incorporate both your changes.

  • Pull the changes from repo1 into repo2; then edit the line you before changed, but in a different way. Push your changes, and then switch back to repo1.

  • This time, pulling from GitLab should cause a merge conflict. Check the difference to your last clean version, and try to resolve the conflict by either accepting one of the versions (“theirs”/“ours”), resolving conflicts in an editor, or using an interactive merge tool. Resolving a conflict includes committing (this continues the merge) the merged files, and explaining your reasoning and choices.

  • Reapply the change you had stashed away in repo1, and check that the difference to your previous repository state is what you would expect.

  • Create a new branch locally, edit the text file and commit your changes. Finally, push the new branch to the repository.

If you like web interfaces, you may well also try what GitLab has to offer.
  • Browse your repository content under the “Files” tab, and perform a quick edit to your text file, committing the change directly from GitLab.

However, especially for more complex operations, I would not recommend this. Use your favourite editors Git integration instead.