List of exercises

Full list

This is a list of all exercises and solutions in this lesson, mainly as a reference for helpers and instructors. This list is automatically generated from all of the other pages in the lesson. Any single teaching event will probably cover only a subset of these, depending on their interests.

Collaborating within the same repository

In same-repository.md:

Exercise: Collaborating within the same repository (25 min)

Technical requirements (from installation instructions):

What is familiar from the previous workshop days (not repeated here):

What will be new in this exercise:

  • If you create the changes locally, you will need to push them to the remote repository.

  • Learning what a protected branch is and how to modify a protected branch: using a pull request.

  • Cross-referencing issues and pull requests.

  • Practice to review a pull request.

  • Learn about the value of draft pull requests.

Exercise tasks:

  1. Open an issue where you describe the change you want to make. Note down the issue number since you will need it later.

  2. Create a new branch.

  3. Make a change to the recipe book on the new branch and in the commit cross-reference the issue you opened (see the walk-through below for how to do that).

  4. Push your new branch (with the new commit) to the repository you are working on.

  5. Open a pull request towards the main branch.

  6. Review somebody else’s pull request and give constructive feedback. Merge their pull request.

  7. Try to create a new branch with some half-finished work and open a draft pull request. Verify that the draft pull request cannot be merged since it is not meant to be merged yet.

Practicing code review

In code-review.md:

Exercise: Practicing code review (25 min)

Technical requirements:

What is familiar from the previous workshop days:

What will be new in this exercise:

  • As a reviewer, we will learn how to ask for changes in a pull request.

  • As a reviewer, we will learn how to suggest a change in a pull request.

  • As a submitter, we will learn how to modify a pull request without closing the incomplete one and opening a new one.

Exercise tasks:

  1. Create a new branch and one or few commits: in these improve something but also deliberately introduce a typo and also a larger mistake which we will want to fix during the code review.

  2. Open a pull request towards the main branch.

  3. As a reviewer to somebody else’s pull request, ask for an improvement and also directly suggest a change for the small typo. (Hint: suggestions are possible through the GitHub web interface, view of a pull request, “Files changed” view, after selecting some lines. Look for the “±” button.)

  4. As the submitter, learn how to accept the suggested change. (Hint: GitHub web interface, “Files Changed” view.)

  5. As the submitter, improve the pull request without having to close and open a new one: by adding a new commit to the same branch. (Hint: push to the branch again.)

  6. Once the changes are addressed, merge the pull request.

How to contribute changes to repositories that belong to others

In forking-workflow.md:

Exercise: Collaborating within the same repository (25 min)

Technical requirements:

What is familiar from the previous workshop days:

What will be new in this exercise:

  • Opening a pull request towards the upstream repository.

  • Pull requests can be coupled with automated testing.

  • Learning that your fork can get out of date.

  • After the pull requests are merged, updating your fork with the changes.

  • Learn how to approach other people’s repositories with ideas, changes, and requests.

Exercise tasks:

  1. Open an issue in the upstream exercise repository where you describe the change you want to make. Take note of the issue number.

  2. Create a new branch in your fork of the repository.

  3. Make a change to the recipe book on the new branch and in the commit cross-reference the issue you opened. See the walk-through below for how to do this.

  4. Open a pull request towards the upstream repository.

  5. Team leaders will merge the pull requests. For individual participants, the instructors and workshop organizers will review and merge the pull requests. During the review, pay attention to the automated test step (here for demonstration purposes, we test whether the recipe contains an ingredients and an instructions sections).

  6. After few pull requests are merged, update your fork with the changes.

  7. Check that in your fork you can see changes from other people’s pull requests.

Collaborating within the same repository

In same-repository-old.md:

Centralized-1: Clone a repository, add a file, push changes as a branch, and create a pull request

  • Before we start with the exercise, instructor points to the preparation (above).

  • Then work on steps A-H.

  • There are also optional exercises.

  • Before and after each action you take, run the following informational commands:

    • git graph - almost every time

    • git status - when you modify files

In same-repository-old.md:

Centralized-2: Merge the pull requests (together)

  • We do step 2A and 2B together (instructor demonstrates, and everybody follows along in their repositories).

In same-repository-old.md:

(optional) Centralized-3: Cross-referencing issues using “#N”

We will submit another change by a pull request but this time we will first create an issue.

  1. Open an issue on GitHub and describe your idea for a change. This gives others the chance to give feedback/suggestions. Note the issue number, you will need it in step 3.

  2. Create a new branch and switch to it.

  3. On the new branch create a commit and in the commit message write what you did, but also add that this “closes #N” (replace N by the actual issue number from step 1).

  4. Push the branch and open a new pull request. If you forgot to refer to the issue number in step 3, you can still refer to it in the pull request form (add a “closes #N” to the title or description).

  5. Note how now commits, pull requests, and issues can be cross-referenced by including #N.

  6. Notice how after the pull request is merged, the issue gets automatically closed. This only happens for certain keywords like closes or fix.

  7. Discuss the value of cross-referencing them and of auto-closing issues with commits or pull requests.

See also the GitHub documentation for more examples.

In same-repository-old.md:

(optional) Centralized-4: Why did we create a feature branch “yourname-somefeature”? (exercise/discussion)

Pushing directly to the main branch is perfectly fine for simple personal projects - the pull-request workflows covered here are for larger projects or for collaborative development. Guidelines for simpler workflows are given in the how much Git is necessary? episode of the git-intro lesson.

In collaborative development, whenever we update our repository we create a new branch and create a pull-request. Let’s now imagine that everyone in your group (or one person on two different clones) makes a new change (create a new file) but without creating a new branch.

  1. You all create a new file in the main branch, stage and commit your change locally.

  2. Try to push the change to the upstream repository:

    $ git push origin main

    You probably see something like this:

    $ git push

To https://github.com/user/repo.git
 ! [rejected]        main -> main (non-fast-forward)
error: failed to push some refs to 'https://github.com/user/repo.git'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again.  See the
'Note about fast-forwards' section of 'git push --help' for details.

  • The push only worked for one participant (one clone).

  • Discuss why push for everybody else in this group was rejected?

Forking workflow

In forking-workflow-old.md:

Distributed-1: Fork a repository and create a pull request

As an example we will collaboratively develop a cookbook for taco recipes, inspired by tacofancy.

Objectives:

  • Learn how to fork, modify the fork, and open a pull request towards the central repository.

  • Learn how to update your fork with changes that others have already made to the forked repository.

Exercise:

  • Maintainer prepares an exercise repository (see above; this will take 5-10 minutes).

  • Learners work on steps A-F (15-20 minutes).

  • There are two optional steps after step E for those who want more.

  • After step E you take a break or help others. Please ask questions both during group work and in the collaborative document.

  • We will review the pull requests together and then update forks.

In forking-workflow-old.md:

(optional) Distributed-2: Send a conflicting pull request

If you complete parts A-E much earlier than others, try to open another pull request where you anticipate a conflict with your first pull request.

In forking-workflow-old.md:

(optional) Distributed-3: Making changes to your pull request after it has been opened.

You can do that by pushing additional commits to the same branch where you opened the pull request from. Observe how they end up added to your pull request.

In forking-workflow-old.md:

(optional) Distributed-4: Squash merge a pull request

If you complete this exercise much earlier than others, create a new pull request with two or more commits.

Then, when reviewing the change as maintainer, accept these with “Squash and merge” and later compare the source and target repositories/branches how they differ after the small commits got squashed into one.

Non-bare and bare repositories

In bare-repos.md:

Bare-1: Create and use a bare repository

  • Create a new local repository with git init.

    $ cd /path/to/example
$ git init

  • Populate it with a file and a commit or two.

  • Create one or two branches.

  • Clone this repository on the same computer with either --bare or --mirror:

    $ git clone --bare /path/to/example /path/to/example-bare

  • Inspect the bare repository.

  • Clone the bare repository:

    $ git clone /path/to/example-bare /path/to/example-clone
$ cd /path/to/example-clone

  • Inside the clone inspect git remote -v.

  • Inside the clone create a commit and push the commit to origin.

  • The bare repository can be cloned several times and one can exercise pushing and pulling changes.