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):

• If you create the commits locally: Being able to authenticate to GitHub

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

• Cloning a repository (previous lesson)

• Creating a branch (previous lesson)

• Committing a change on the new branch (previous lesson)

• Submit a pull request towards the main branch (previous lesson)

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. If you work locally and not on GitHub, you need to clone the repository to your computer before you can create a new branch (more details in “Solution and hints” below).

3. Create a new branch.

4. 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).

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

6. Open a pull request towards the main branch.

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

8. 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:

• If you create the commits locally: Being able to authenticate to GitHub

What is familiar from previous episodes:

• Creating a branch (previous lesson)

• Committing a change on the new branch (previous lesson)

• Opening and merging pull requests (previous lesson)

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:

• If you create the commits locally: Being able to authenticate to GitHub

What is familiar from the previous episodes:

• Forking a repository (previous lesson)

• Creating a branch (previous lesson)

• Committing a change on the new branch (previous lesson)

• Opening and merging pull requests (previous lesson)

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.

In forking-workflow.md:

Recovery

But if you want to keep your local changes, you can change the remote URL to point to your fork. Check where your remote points to with git remote --verbose.

It should look like this (replace USER with your GitHub username):

$ git remote --verbose

origin	git@github.com:USER/forking-workflow-exercise.git (fetch)
origin	git@github.com:USER/forking-workflow-exercise.git (push)

It should not look like this:

$ git remote --verbose

origin	git@github.com:cr-workshop-exercises/forking-workflow-exercise.git (fetch)
origin	git@github.com:cr-workshop-exercises/forking-workflow-exercise.git (push)

In this case you can adjust “origin” to point to your fork with:

$ git remote set-url origin git@github.com:USER/forking-workflow-exercise.git

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.