Issues and project context
Use a remote, pull request and automated check to propose a reviewable change.
THE IDEA
An issue is the reason a change exists
Code shows what changed. An issue records why: the problem, how to see it, and what "fixed" means. Months later, git blame leads to a commit, the commit leads to an issue number, and the issue explains the decision. A report that just says "broken" cannot be acted on, because the person fixing it must guess the inputs.
Title: Cart total is wrong when an item has quantity 0
Steps to reproduce:
1. Add an item with quantity 0
2. Open the cart
Expected: the total ignores the item.
Actual: the total includes its price.New issue (simulated page)
- ○ The title does not say what is wrong. Name the feature and the symptom.
- ○ No steps to reproduce.
- ○ No expected behavior.
- ○ No observed (actual) behavior.
Predict first. An issue says only: "Checkout is broken." Is that enough to start fixing it?
Linking work to issues
Put #12 in a commit message or pull request and the service links the two, so the issue page shows "mentioned in commit abc1234". Put a closing keyword before it (Fixes #12, Closes #12, Resolves #12) and the issue closes by itself when that commit reaches the default branch. Pushing it to a side branch only links it; the work is not delivered yet.
The message closes: #1. It only mentions: nothing.
- ○ open #1 Checkout rounds prices wrongly
- ○ open #2 Add dark mode
- ○ open #3 Docs: explain environment variables
Chapter context
GitHub hosts repositories and adds collaboration around Git objects. A pull request is a review and discussion mechanism; the commits and branch history still follow Git rules.
TRY IT YOURSELF
The repository is cloned in ~/shop. Open issues: #1 (README has no install steps) and #2 (checkout is slow). main is not protected here, so you can push to it directly.
- Issue #1 is about missing install steps. On a branch named fix-docs, add docs/install.md and commit it with a message that says it fixes #1. Push the branch (not main)
- Mention issue #2 on main WITHOUT closing it: commit with the text Refs #2 and push main. Issue #2 must stay open but record the mention
- Land fix-docs on main and push. Watch issue #1 close by itself because of the keyword in the commit
Steps in the simulated website
- ○File a good bug report in the panel: a specific title, steps to reproduce, expected and actual behavior
Issues
- open #1 README has no install steps
- open #2 Checkout is slow with 500 items
New issue (simulated page)
- ○ The title does not say what is wrong. Name the feature and the symptom.
- ○ No steps to reproduce.
- ○ No expected behavior.
- ○ No observed (actual) behavior.
Your repository (0 ahead, 0 behind origin/main)
The server
Stuck, or something not working? You can come back to it any time.
CHECK YOUR UNDERSTANDING
Is 'broken' sufficient reproduction information?
Chapter reference: math, worked example & code
This section belongs to the whole chapter, so it is the same on every lesson in it and may cover a different lesson's topic. The code for the experiment you just ran is inside the experiment itself.
Math and notation
For independent jobs with durations t1 and t2 running simultaneously, ideal elapsed time is max(t1,t2), excluding startup and queueing. A dependency adds a sequential edge and can make durations add instead.
Worked example
A build takes 3 minutes. Two test jobs taking 4 and 6 minutes start after the build and run together. The ideal critical path is 3 + max(4, 6) = 9 minutes, not 13. Real runners can add scheduling overhead.
Reference code
The following example uses the Python standard library and does not call a remote service.
build, tests = 3, [4, 6]
assert build + max(tests) == 9
assert build + sum(tests) == 13
Python examples are provided for study and local execution; this page does not execute Python.
Common mistakes
A green check is evidence for the checks that ran, not proof of every behavior. Forked code must not automatically receive trusted secrets.