Chris Zhou, 2022-10-14
- Code
- Coder
- Code design
- Coding
- Code review
- Author(s)
- Reviewer(s)
- Commits
- Diffs
- Discussions
A pull/merge request is a request to merge code changes.
It integrates all elements of code reviews:
- View commits and diffs.
- Enable discussions between authors and reviewers.
Who enjoys reviewing complex merge requests?
Who enjoys merge request conversations that are difficult to track over time?
Who enjoys not being able to close merge requests?
Code reviews > Code
Sell your code to ship your code.
Our code, not my code.
Assume an AI Overlord.
Value (
git) history.
Author the history with meaningful commits.
Coauthor the history with others.
Consider your audience/reviewers. Do they have context? Does context need to be established?
Consider primary reviewers.
Keep merge requests isolated (not small).
Build a habit of breaking code changes into commits with isolated responsibility. Review by commits.
Have meaningful merge request summary, test plans to build searchable metadata.
Focus less on the outcome of shipping code, and more on the process of reviewing code with others.
Always consider your role (e.g. primary author/reviewer). Am I blocking others?
A bad history
c1: implement page X
A better history
c1: update state
c2: update tests
c3: fix bug in A and B
c4: install deps
c4: bootstrap page X
A complete history
c1: feat(workflow): register tickets state
c2: test(A): add tests
c3: test(B): add tests
c4: fix(A): fix against c2
c5: fix(B): fix against c3
c6: deps: install D1 and D2
c7: feat(PageX): bootstrap
- Conventions adding semantics and structure for commit messages.
- Link
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
fix: handle Y in X
fix!: handle Y in X (with breaking changes)
fix(X): handle Y
feat: support Y in X
feat!: support Y in X (with breaking changes)
feat(X): support Y
build: update deps
chore: cleanup package.json
docs: update Y for X
docs(X): update Y
test: test Y in X
test(X): test Y
- Generate changelogs and release notes from a project's commit messages and metadata
- Because there is consistent structure in git commits, Semver and breaking changes can be systematically generated.
- Link
[1.2.1](link to commit) (YYYY-MM-DD)
## Fixes
### [commit.domain]
- [commit.id]: commit.message
## Features
### [commit.domain]
- [commit.id]: commit.message
## Breaking Changes
### [commit.domain]
- [commit.id]: commit.message- Lint commit messages to ensure consistent and compliant structure.
- Link
This presentation is written entirely in Markdown (CommonMark).
It is presented using md-slides (a hacked POC) utilizing the following microlibraries: