ComputeSphereLearn
Console
Learning paths / Application foundations / GitHub

Repositories and pull requests on GitHub

Reading · 6 min · Module 7, lesson 1 of 537 min left in this module

Module 7 · GitHubLesson 1 of 5

Goal: Push a branch to GitHub and open a pull request with a useful description.

3:51 · captions and chapters · narrated with an AI-generated voice
Transcript

Narration uses an AI-generated voice.

[00:00] Where we're going

By the end of this video, you'll know how your work gets from a branch on your machine into main, on GitHub. Branch. Push. Pull request. Review. And merge.

[00:12] A remote

GitHub keeps a shared copy of your repository. That copy is called a remote. Everyone on the team pushes to it, and pulls from it. When you clone a repository, Git names the copy you cloned from origin.

Here's a real clone of one of the Learn samples. Ask Git for its remotes, and origin points back at the repository on GitHub.

To send your branch there, you push it to origin. The first time, add the u flag. It links your local branch to the one on GitHub, so after that, a plain push is enough.

[00:49] On GitHub

Here's the Learn samples repository on GitHub. The code on main, its branches, and a tab for pull requests. Every commit that reaches main shows up in its history, newest first. See the number at the end of each one? Each of these arrived through a pull request.

[01:08] Clone or fork?

Clone when you can push to the repository. Your own, or your team's. Fork when you can't. Someone else's project, or a sample like this one. A fork is your own copy, under your account. You push to it, and open pull requests from it.

[01:27] A pull request

Once your branch is on GitHub, you open a pull request: a request to merge it into another branch, usually main. Here's one from the samples repository. Main is the base: the branch you merge into. The branch with the work is the compare branch. This one has already been merged.

[01:47] Four parts

The page has four parts that matter. First, the title. What the change does, in a few words. Second, the description. Why the change is needed, what it does, and how it was checked. The reviewer reads this before the code. Here, the last paragraph says exactly what was tested.

[02:08] The diff and checks

Third, the diff. The Files changed tab shows every line added, and every line removed. Red lines are removed. Green lines are added, compared with the branch you're merging into. Fourth, checks. Automated jobs, such as tests, that run on every push to the branch. This sample doesn't set any up, so the count is zero. Lesson two point seven point four shows where checks come from.

[02:38] A useful description

A reviewer can't ask you what you meant, so give them what they need up front. Why. Users with many tasks can't find one quickly. What. A search box on the task list, where matching ignores case. And how you checked. The tests pass, and a search for milk, in any case, finds Buy milk. Keep one change per pull request. Two changes in one means two reviews, and the second hides the first.

[03:08] Review and merge

Then others review it: the description, then the diff, before anything lands. When it's ready, the pull request is merged, and your branch's commits land in main. So, one more time. Branch, push, open a pull request, get it reviewed, and merge.

Check yourself. You want to change a sample repository you can't push to. What do you do? Fork it, then push your branch to the fork. A clone still can't push back. Two lessons from now, you'll fork a sample, and open and merge a pull request yourself. See you there.

Key idea

GitHub keeps a shared copy of your repository. You push a branch to it, then open a pull request: a request to merge that branch into main, with a description, the diff and the results of automated checks on one page, where others can review it before it lands.

Your repository has a remote

In module 5 your commits and branches lived on your machine. A remote is another copy of the same repository, usually on GitHub, that everyone on the team pushes to and pulls from. When you clone a repository, Git names the copy you cloned from origin.

git remote -v          # where origin points
git push -u origin add-search   # send your branch to GitHub

-u links your local branch to the one on GitHub, so from then on a plain git push is enough.

Signing in to GitHub to push

GitHub doesn't accept your account password for git push. The simplest way in is the GitHub CLI: install gh, run gh auth login, and choose HTTPS; it sets Git up to push as you. The alternative is a personal access token, pasted when Git asks for a password. Check the current steps in GitHub's docs, at docs.github.com under "Authenticating with GitHub from Git".

Clone or fork?

  • Clone when you can push to the repository: your own, or your team's. You get a local copy; your branches go back to the same repository.
  • Fork when you can't: someone else's project, or a sample. A fork is your own copy of the repository under your GitHub account. You push to your fork and open pull requests from it.

You'll fork a sample in the next-but-one lesson, and again in Path 5 to deploy from it.

The parts of a pull request

When you push a branch, GitHub offers to open a pull request for it. The page you get has four parts that matter:

  1. Title. What the change does, in a few words: "Add search to the task list", not "Fixes".
  2. Description. Why the change is needed, what it does, and how you checked it. The reviewer reads this before the code.
  3. The diff. The Files changed tab shows every line added and removed, compared with the branch you're merging into.
  4. Checks. Automated jobs the repository sets up, such as tests, that run on every push to the branch and report a pass or a fail on the page. Lesson 2.7.4 shows where they come from.

The branch you merge into is the base (usually main); the branch with your work is the compare branch.

A description worth reading

A reviewer can't ask you what you meant at 11pm. Give them what they need up front:

## Why
Users with many tasks can't find one quickly.

## What
Adds a search box to the task list. Matching is case-insensitive.
No new dependencies.

## How I checked
npm test passes. Searched for "milk" and "MILK" locally: both find "Buy milk".

Keep one change per pull request. A pull request that adds search and also renames every file is two reviews squeezed into one, and the second one hides the first.

Draft pull requests

If you want early feedback on unfinished work, open it as a draft: next to Create pull request, open the dropdown and choose Create Draft Pull Request. A draft can't be merged until you mark it ready for review.

Check yourself

You want to change a sample repository you can't push to. What do you do?
Which pull request description helps a reviewer most?