Lab: Pull Requests

Starter code: github.com/rtealwitter/pullrequest-tutorial

Git has a well-earned reputation for being hard. It is also fundamental to working as a programmer, and it has only grown more important as more of our code is written with AI: the tools change, but the workflow for saving, sharing, and combining code stays the same.

Boromir meme: 'One does not simply understand git.'

This lab walks you through the three concepts that turn git from a personal save button into a collaboration tool: branching, merging, and pull requests. Every earlier lab used git alone, to submit your own work. Here you use it the way real projects do, where many people change the same code and git keeps their work from colliding. This is the loop behind nearly all software, open-source and otherwise, so it is worth doing carefully.

Getting the code

  1. Fork the starter repository, github.com/rtealwitter/pullrequest-tutorial, to your own GitHub account with the Fork button. You now have your own copy that you are allowed to push to.

  2. Clone your fork to your laptop and open the folder in VS Code:

    $ git clone https://github.com/<your-username>/pullrequest-tutorial
$ cd pullrequest-tutorial

Part 1: the terminal and git

Inside the repository you just cloned is a folder named git-tutorial with its own README. Work through it top to bottom, typing every command into your terminal as you go. It is a self-guided walkthrough (you can also read it on GitHub), and it covers the core of everyday git:

  • committing changes and reading your history with git log,
  • branching, so you can build a feature without disturbing the working version,
  • merging a finished branch back in,
  • resolving a merge conflict by hand, when two branches change the same line,
  • and cleaning up branches once you are done with them.

The tutorial deliberately uses a few commands we have not covered in class. That is the point: it is partly practice with git, and just as much practice at following a technical tutorial on material you have not seen before, which is most of what learning to program actually looks like. There is nothing to submit for this part; it sets up the pull request in Part 2.

Part 2: your first pull request

Now put it to use on a real change.

The README of the repository you forked has a deliberate typo in its title: it reads Tutrial where it should read Tutorial. Because the project lives on GitHub, you can use git to fix that mistake and offer the fix back, which is exactly what a pull request is: a proposed change to someone else’s repository that the owner can review and merge.

The shape of the workflow is the one from Part 1, now spanning two copies of the repo. On your fork you make a branch, fix the typo, commit, and push; then you open a pull request asking the original repository to pull your change in. For the exact click-by-click steps, follow this seven-step procedure. It was written for working programmers rather than for this class, which is the point again: reading documentation aimed at professionals is a skill this lab is here to build.

Note. Since everyone submits the same pull request for this one intentional typo, these particular pull requests will not be merged. But if you ever find a genuine mistake in a class repository, send a pull request to fix it. It will be accepted, you will get extra credit, and everyone benefits from the correction.

Submitting

This lab does not work like the auto-graded labs, and that is on purpose. There are no doctests to pass and no green badge to earn; the workflow itself is the deliverable. When your pull request is open on GitHub, you are done: submit the URL of your pull request on Gradescope.

The skill you just practiced, contributing a change through a fork and a pull request, is how you will work on every shared codebase from here, including the group projects later in this course.