GitHub pull requests and useful review

A pull request is a hosted proposal

A GitHub pull request proposes integrating a head branch into a base branch and gathers discussion, commits, checks, and file changes. It is not a Git object stored automatically in every clone. Choosing the wrong base can produce a misleading comparison and target the wrong maintenance line. Draft status communicates work in progress and prevents merging under the platform’s draft rules, but does not make an unsafe workflow safe to execute. Feature availability and repository controls depend on account, plan, permissions, and current configuration, so inspect the actual repository policy before assuming a merge button means permission to proceed.

Explain behavior and evidence

A useful description names the concrete problem, resulting behavior, scope, validation, and material limits. Keep it understandable to someone who has not read the chat or issue history. Separate observed test results from assumptions and identify migration or compatibility concerns. The example below is a synthetic review note, not a submitted message or an actual pull request. A concise description can be sufficient when the change is simple; larger behavior changes need enough context for reviewers to evaluate consequences without reconstructing intent from every modified line.

GitHub can prefill new pull-request bodies from a supported template file available on the default branch. A template prompts authors for evidence; it does not verify their answers or submit a review. The example below is file content only and is not installed in any real repository.

Problem: blank notebook titles were accepted.
Behavior: titles are trimmed and rejected when empty.
Validation: boundary tests cover spaces, a valid title, and unchanged content.
Limit: no database schema changes are included.

## Behavior
Describe the concrete user-visible change.

## Validation
Record tests and the candidate revision actually checked.

## Risks
State migration, compatibility, and untested assumptions.

Inspect the candidate locally before requesting review

Review the topic against its intended base using a merge-base comparison, then inspect the commit list and whitespace checks. The commands below operate only on named local lab refs. A three-dot diff answers what the topic changes from the common base; it may differ from an endpoint comparison when main has progressed. git diff --check can detect whitespace errors and conflict markers under its rules, but it is not a compiler or business test. Use the project’s relevant tests and inspect generated, deleted, and sensitive files deliberately before presenting the change.

git log --oneline main..feature/title
git diff --stat main...feature/title
git diff --check main...feature/title

Distinguish feedback from enforced policy

GitHub reviews can comment, approve, or request changes. Whether a review blocks merging depends on configured rules and reviewer authority. Required checks, code-owner review, conversation resolution, signed commits, and merge queues are separate controls that may apply. An approval refers to reviewed content; later commits can change the risk and may invalidate approval under configured rules. Review the current revision and explain unresolved questions. A green check indicates that its configured execution succeeded, not that every requirement was evaluated. Treat automated and human evidence as complementary and keep ownership of the final integration decision explicit.

Choose a history result deliberately

A platform merge commit, squash merge, and rebase-and-merge produce different history shapes and commit identities. Repository settings determine which options are available. Squashing can make one coherent destination commit while leaving original topic commits outside its ancestry; therefore local branch-deletion checks may not recognize patch equivalence as merged ancestry. Rebase methods replay changes and can alter identifiers. Follow the project convention and explain important context in the resulting message. After integration, verify the destination and close the collaboration loop without assuming a merged pull request automatically proves release, deployment, or cleanup has occurred.