Git branches and pull requests for a student project

A pull request is evidence of reasoning, not only a merge button. A reviewer should understand the change, validation and risk without reconstructing the author’s terminal history.

Inspect a PR record

The engineering foundations lab creates a local fixture.

from engineering_cases import pull_request_case

result = pull_request_case()
assert result["complete"] is True
assert result["pr"]["branch"] == "feat/order-validation"
assert result["pr"]["evidence"] == ["pytest: 8 passed"]
assert result["merged"] is False
assert result["remote_created"] is False

No branch or PR was created.

Keep one coherent change per branch, commit understandable steps and sync with the target branch before requesting review. The description should state trigger/problem, resulting behaviour, tests, screenshots for UI when relevant, migration/rollback and known limits.

Review the diff yourself, remove secrets and generated noise, and respond to feedback with code or a reasoned discussion. Required checks should pass before merge. Preserve authorship and avoid rewriting shared history casually.

The FDE for Freshers course uses PR evidence in the CLI, integration and capstone projects.

Exercise

Create a local feature branch for one validation rule, make two clear commits, write the PR description and ask a peer to review the diff before any merge.

Continue learning

This article is part of the FDE engineering foundations sequence. Use the neighbouring tasks when you need the prerequisite or the next application.

• Review the prerequisite or neighbouring task in Write logs that make a failed request diagnosable.
• Continue with Resolve a Git conflict by understanding both changes.

Reference: GitHub pull-request documentation.