Last updated on

Git I: Single-user version control

Here are a few questions, exercises, and resources to guide your exploration of version control systems. Please do ask on Ed or in exercise sessions if anything is unclear!

If you ask a complex Git question on Ed, it will often be much easier for us to help you debug if you include a copy of your repo. For this, post your repo as a git bundle in a private Ed post (look up the documentation of git bundle to know what it does).

Make sure you have good backups before experimenting with your computer on the command line!

As usual, ⭐️ indicates the most important exercises and questions and 🔥 indicates the most challenging ones.

You do not need to complete all exercises to succeed in this class, and you do not need to do all exercises in the order they are written.

Browsing documentation

The official Git tutorial is distributed as manual (man) pages. On macOS, GNU/Linux, and WSL, you can simply type man command to get more information about command. On Windows, you may prefer to browse the online Git documentation instead.

  1. Locate the commands that we discussed during the lecture in man gittutorial, man gittutorial-2, and man giteveryday.

  2. Look up concepts and commands you don’t know in man gitglossary.

Configuration ⭐️

  1. To use Git, you need to configure your user name and email. Look up the corresponding git config commands online, or follow the instructions in man gittutorial. This ensures that your commits carry the right author information.

  2. git commit and other interactive commands sometimes need to open a text editor. Use git config to set the core.editor variable globally to your preferred editor. (The demo given in class used Emacs. On GNU/Linux, Git typically defaults to nano, which is reasonably intuitive, while on macOS it defaults to vi, which is great but not too beginner-friendly. For this course, we recommend VSCode.)

Reproducing the first Git demo

  1. ⭐️ Re-watch the 15-minutes Git demo that was given at the end of the first Git lecture and follow along on your own terminal (use “Git bash” on Windows). Which commands were necessary? Which were just for demo purposes? (If you run into any issues, try reading the corresponding manual pages.)

    (If you prefer to read, you can follow this written transcript instead.)

  2. Notice the file called .gitignore. What is this file for? What would git status have shown after sbt run if sbt new hadn’t created it? (Try it! Replicate the commands, then delete .gitignore and see what git status shows.)

Browsing history

  1. Clone a large repository, using the git clone command. For example:

    git clone https://github.com/microsoft/vscode.git

  2. Read up on the git blame command. What does it do? Try it on the command line on a file in the repository you just cloned.

  3. Graphical interfaces can be useful to browse complex history. Find out how to perform a git blame and a git log restricted to a set of lines in your favorite editor, as demonstrated at the end of the demo (the demo used Emacs with magit as the Git UI; you can use VSCode with the Gitlens plugin).

Tracking history and creating patches ⭐️

  1. ⭐️ Initialize a new git repository to hold a copy of your exercise solutions. Make a commit after downloading your next set of exercises, and after completing each exercise.

  2. If you forget to commit between two exercises, find a Git command or a tool in the VSCode UI that lets you stage only part of your changes (hint).

  3. ⭐️ Use git format-patch to share the solution to one exercise with a classmate. Use git am to apply a patch received from a classmate.

  4. 🔥 What happens if you try to apply the patch after you’ve already started solving the same exercise? Look up how to handle the resulting situation, which is known as a conflict in Git.

Exploring large codebases ⭐️

  1. On your computer, locate at least one free software (“open source”) application that you use regularly, and find out how to get its source code. Is it hosted in a Git repository?

  2. Many projects are hosted on Git platforms such Github or Gitlab. Does Git require you to use such a platform?

  3. Clone a git repository of an application that you use and explore the history. Find Git commands to answer the following questions:

    1. What happened in the last three days?
    2. Who contributed to writing the README file?
    3. What is the most recent commit that mentions a bug fix? How did the fix work? When was the buggy code introduced (in which commit?) How long did the bug remain?

  4. 🔥 Sometimes you want more information than Git alone can provide directly. Find a way to answer the following questions:

    1. How many C source files does the repository contain?
    2. Which files had the most changes over the last 2 years?
    3. Which is the most commonly edited files in commits that mention a bugfix?
    4. Which was the largest commit (in terms of changed lines) in the last 3 months?

Being a good Gitizen

  1. Browse a few popular repositories on Github or Gitlab. Look in particular at the commit messages. Do they use a consistent format? If you’re not sure where to look, a good example is the Spark repository.

  2. ⭐️ Some projects take Git commits and change logs very seriously. Pick a free software project and find its contributor guidelines. What do they recommend doing for commits? If you don’t find great examples, see these GNU guidelines, these PostgreSQL ones, and these from Git itself.

© 2023, 2024 EPFL. All rights reserved.