38 lines
1.2 KiB
Markdown
38 lines
1.2 KiB
Markdown
|
## Commit and sync
|
||
|
|
|
||
|
|
### 1. Review before committing
|
||
|
|
|
||
|
|
Read the actual diff, not just the file list. For each change, decide whether it
|
||
|
|
is finished, half-finished, or debris — scratch files, commented-out
|
||
|
|
experiments, stray debug output. Do not commit debris; do not silently delete
|
||
|
|
work either. Say what you found.
|
||
|
|
|
||
|
|
If a change looks wrong or you cannot tell what it was for, ask rather than
|
||
|
|
committing it.
|
||
|
|
|
||
|
|
### 2. Commit in coherent units
|
||
|
|
|
||
|
|
Group changes so each commit is one reviewable idea. A commit message says what
|
||
|
|
changed and **why**, in prose, with the reasoning that will not be recoverable
|
||
|
|
from the diff six months from now. Do not enumerate the diff — the diff is
|
||
|
|
already there.
|
||
|
|
|
||
|
|
If the working tree contains two unrelated pieces of work, make two commits.
|
||
|
|
|
||
|
|
### 3. Sync
|
||
|
|
|
||
|
|
Run the repo's sync step so the hub reflects the files. Report what it did,
|
||
|
|
including any warnings it left standing and whether they matter.
|
||
|
|
|
||
|
|
### 4. Report
|
||
|
|
|
||
|
|
State plainly:
|
||
|
|
|
||
|
|
- what was committed, and in how many commits;
|
||
|
|
- what was left uncommitted and why;
|
||
|
|
- the sync result;
|
||
|
|
- anything you noticed that needs a decision from me.
|
||
|
|
|
||
|
|
If nothing was ready to commit, say so. An empty commit round is a valid
|
||
|
|
outcome, not a failure to be papered over.
|