Pull requests

A pull request (PR; a "merge request" on GitLab) asks the maintainers to add your commits to their project. It is where your change is tested, discussed and, at the end, merged.

From fork to pull request

You cannot push to someone else's repository, so you work on your own copy, a fork:

# 1. On GitHub, press "Fork" on the project's page. Then:
git clone https://github.com/YOU/mylib.git
cd mylib
git remote add upstream https://github.com/OWNER/mylib.git

# 2. One branch for each change
git switch -c fix-empty-average

# 3. Change the code, add a test, run all the tests
git add mylib/stats.py tests/test_stats.py
git commit -m "Return 0 from average() for an empty list"

# 4. Send the branch to your fork
git push -u origin fix-empty-average

GitHub then offers a Compare & pull request button. origin is your fork; upstream is the original project.

Tests come with the change

def average(numbers):
    if not numbers:
        return 0
    return sum(numbers) / len(numbers)


def test_normal():
    assert average([4, 8, 6]) == 6


def test_one_number():
    assert average([5]) == 5


def test_empty_list():
    assert average([]) == 0


# pytest finds and runs every test_ function by itself; here we call them.
for test in [test_normal, test_one_number, test_empty_list]:
    test()
    print("passed:", test.__name__)
Open in compiler

A bug fix should add a test that failed before the fix and passes after it. Most Python projects use pytest: it finds every function whose name starts with test_ and runs it. Here the loop at the bottom does pytest's job, so you can watch each test run.

Writing the description

Fixes #42

average() raised ZeroDivisionError for an empty list. It now returns 0,
as agreed in the issue.

Testing: added test_empty_list; all tests pass (pytest).

Say what changed, why, and how you tested it. "Fixes #42" links the issue, and closes it when the PR is merged.

After you open it

  • Checks (CI) run the tests and the style tools on your code. If one is red, open its log, fix the problem and push again.
  • Reviewers comment. Answer each comment, make the changes, then commit and push to the same branch: the PR updates itself.
  • If main moved on, update your branch: git fetch upstream, then git rebase upstream/main, then git push --force-with-lease.

Keep a PR small and about one thing. A 30-line fix gets reviewed in a day; a 3,000-line PR that also reformats every file may never be.

Quick check

1. Why do you fork a project before your first PR?
2. A reviewer asks for a change. What do you do?
3. What should a bug-fix PR include?

Practice problems for this lesson

My notes

Write down what you want to remember from this lesson. Notes are saved on this device as you type, and appear on your dashboard.