Every command in this course so far is a building block. This lesson is how they combine into the habits a real team (or a disciplined solo developer) actually follows day to day.
| Step | Command(s) |
|---|---|
| 1. Start from an up-to-date main | git switch main && git pull |
| 2. Create a branch for one specific change | git switch -c feature/user-login |
| 3. Commit in small, logical steps | git add ... && git commit -m "..." |
| 4. Push and open a pull request | git push -u origin feature/user-login |
| 5. Address review feedback with more commits | Same branch, more commits, pushed again |
| 6. Merge once approved, then delete the branch | Usually done through GitHub's merge button |
| Prefix | For |
|---|---|
| feature/... | A new feature |
| fix/... | A bug fix |
| chore/... | Maintenance work — dependency updates, config changes |
| docs/... | Documentation only |
A widely-used commit message format that makes a project's history scannable and machine-parseable (some tools auto-generate changelogs from it).
feat: add password reset flow
fix: correct off-by-one error in pagination
docs: update README installation steps
refactor: simplify user validation logic
test: add coverage for edge cases in checkout
chore: bump dependency versionsOne commit per logical change, not one commit per work session — a commit fixing a bug and a commit adding an unrelated feature should never be the same commit, even if they happened back to back.
A gut check for commit size
A useful test for commit size: could this specific commit be reverted on its own, cleanly, without breaking something unrelated? If not, it's probably bundling more than one logical change.