Last updated: October 4, 2026
After completing this codelab, students will be able to:
main, develop, feature/*, fix/*);flutter analyze, dart format) until clean;week5_offline_notes, campus_notify, or the Week 7 Clean Architecture refactor). This codelab reviews that project; it does not start a new one.user.name and user.email).One branch, one purpose:
| Branch | Role | Rule |
|---|---|---|
main | Always releasable, protected | No direct commits; release only |
develop | Weekly feature integration | Default target of all pull requests |
feature/* | Daily single-feature work | Short-lived (< 3 days), branched from develop |
fix/* | Quick fixes + tests | Include reproduction steps in the issue |
main -> always releasable, protected
develop -> weekly feature integration
feature/* -> daily work, short-lived
fix/* -> quick fixes + testsOne commit = one logical change that can be reviewed and reverted:
good: feat(notes): validate empty title + test
good: fix(auth): refresh token before one retry
bad: fix bug / update / final fix for realUse the type(scope): short description format with types feat, fix, refactor, test, docs, chore.
Small PRs get reviewed fast; huge PRs scare reviewers. A review-ready PR must have:
flutter analyze clean and flutter test green before requesting a reviewer.Every PR starts from a clear issue and closes it automatically:
issue #42 -> branch fix/42-login-crash
-> small commits -> PR "Closes #42"
-> review -> merge -> issue closedRun inside your Week 5–7 project repository:
git log --oneline -15
git branch -a
git statusFlag problems: direct commits to main, fix bug/update messages, branches older than 1 week, or untracked files that should be committed or ignored.
git checkout develop
git pull origin develop
git checkout -b feat/notes-validation
# make one small change ...
git add -p
git commit -m "feat(notes): validate empty title + test"
git push -u origin feat/notes-validationUse git add -p so each commit holds exactly one logical change, not every touched file.
Create a before/after table in docs/review-checklist.md: rewrite 3 of your old commit messages into the conventional format with reasons. Example: fix bug → fix(notes): prevent saving empty titles + test (clear what, where, and the proof).
From the feat/notes-validation branch, open a PR to develop with this template:
Title: feat(notes): validate empty title + test
Problem: users can save notes without a title.
Solution: validation in the use case + error in UI.
Test steps: 1) add an empty note -> error shows.
2) flutter test test/validate_note_test.dart
Closes #12Swap PRs with another pair. Each reviewer must produce at least:
Use the observation → impact → concrete proposal pattern:
Weak: "this code is bad, fix it"
Good: "This build function is 60 lines with 3 jobs.
Suggestion: extract validation to core/validate.dart.
Reason: unit-testable without widgets."Be tough on code and kind to humans. Every comment must be actionable without follow-up questions.
Authors fix the findings, request re-review, then merge — squash when the intermediate commits are messy. Make sure the issue auto-closes and the branch is deleted after merging so the branch list stays short.
Run these three commands in your project; all must be green before requesting review:
flutter analyze
dart format --set-exit-if-changed .
flutter testReading the output: unused_import → remove dead imports; prefer_const → use const for cheaper rebuilds; must_be_immutable → widgets must stay immutable. Fix errors first, then warnings, then info.
Create a minimal .github/workflows/ci.yml so machines reject dirty PRs before humans read them:
name: ci
on: [pull_request]
jobs:
verify:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: subosito/flutter-action@v2
- run: flutter analyze
- run: flutter testFill in docs/review-checklist.md: proven feature-first structure (the three Week 7 sterility greps), clean analyze, green tests, small PRs + clear commits, a complete README + screenshots + run guide, and every review comment addressed. What counts is not feature quantity but a foundation trusted for part two.
AI may be a fast, thorough first reviewer, but you decide. A wrong AI review (flagging a non-existent bug, proposing an architecture-violating pattern) is more dangerous than no review.
Ask an AI coding assistant to review your PR with this prompt:
Review this Flutter PR as a senior Flutter dev.
Context: feature-first Clean Architecture
(presentation -> domain <- data),
Riverpod, GoRouter, SQLite + Dio.
Focus: correctness, architecture, tests. Ignore style.
Give the top 5 findings + severity (blocker/suggestion)
+ rationale + proposed code fix.Before applying any AI suggestion, verify and record it in docs/ai-review-vs-decision.md:
dart format and make CI reject dirty PRs.Every behavior-changing PR must include test evidence:
flutter analyze
flutter test
# + 5-minute manual test per feature + screenshots| Symptom | Common cause | Fix |
|---|---|---|
| An 800-line PR never gets reviewed | Many features merged into one PR | Split per feature; one PR < 300 lines |
| Repeated merge conflicts | Long-lived branches, rare syncs | Rebase/pull develop daily; branches < 3 days |
| Reviews only debate spacing | No formatter/CI | Require dart format + analyze CI |
Approved but bugs slip through | Review without pulling + testing | Reviewers must check out, run, and test manually |
| AI advice breaks architecture | AI accepted raw without verification | Reject with reason + grep/test evidence |
develop, small one-feature PR, issue closed via PR.flutter analyze clean, dart format tidy, flutter test green.docs/.Continue your portfolio repository (extend the Week 5–7 project, not a new project) and prove collaboration discipline:
feature/* → develop).flutter analyze + flutter test results in the README.docs/.08-week-8-mid-project-review/ with docs/, README.md, and screenshots/. The README explains the mid-semester status, the issue/PR map, main features, tech stack, how to run, and the result achieved.