Workflow
/finishFinishing is a decision, not a Git push.
Completion needs a disposition
Working code still needs a destination
The implementation is complete and the tests are green. That proves something about the change. It does not decide where the change belongs. A finished piece of work still needs an explicit disposition: integrate it, send it through review, preserve it for later or discard it.
In Git, that moment often appears at the end of a branch, an isolated line of development. The principle is broader than Git. A document draft, automation rule, model prompt or configuration change also needs a destination. Stopping work is not the same as deciding what happens to it.
Green evidence still needs a destination
Finishing chooses what should happen to verified work based on policy, risk and collaboration.
Integrate now
- Merge directly Low-risk work within explicit authority.
- Route through review Consequential or collaborative change needs another decision.
choose by policy and consequence
Do not integrate yet
- Park with context Useful work is incomplete or waiting on a dependency.
- Discard deliberately The experiment taught enough, but the change should not survive.
A commit records work. It does not decide whether the work belongs in the product.
Four named dispositions
Merge, review, park or discard
Merge means integrate the work into the shared version that can ship. Use it only when policy allows direct integration and the evidence matches the risk. Review means place the work in front of another person or required approval process before integration, often through a pull request. Review is a gate, not a final destination. It should end in merge, further change, parking or discard.
Park means preserve the work intentionally because its timing or dependency is unresolved. Record an owner, the reason and a review date so parking does not become abandonment. Discard means delete the implementation after preserving any lesson or evidence worth keeping. Exploration can be valuable even when its code should never become production maintenance.
Choose with five criteria. Blast radius: how many people or systems can a mistake affect? Reversibility: can the outcome be undone, not merely the code rolled back? Policy: is review required for this class of change? Collaboration: who needs to understand or coordinate around it? Maintenance: what will the organisation have to operate, secure and explain after the merge?
Green tests establish evidence about the implementation. They do not choose its destination.
A worked decision
The patch passed, but the payment risk did not
Suppose an agent implements an automatic retry after a payment provider times out. The focused tests pass. Direct merge is still the wrong disposition. The blast radius includes every affected customer. Rolling the code back would not reverse a duplicate charge. Payment policy requires review. Finance and support need to understand the customer outcome, and the retry creates monitoring and incident work.
The team sends the change to review with traces from timeout cases and a duplicate-charge test. Review reveals that the patch creates a fresh idempotency key, a client-supplied token that should make repeated payment requests count as one operation, on every retry. The provider's approved flow requires the original key to be reused after a timeout. The team discards the retry implementation, records the provider behaviour and opens a smaller change that preserves the key across retries and monitors duplicate attempts.
Discarding the first implementation is not wasted work. It produced evidence that changed the remedy. The lesson survives; the maintenance burden does not. That is the same discipline as treating “done” as a claim: the disposition should follow the evidence, not the effort already spent.
Make the decision routine
A finishing gate that fits the workflow
Put the disposition question into the working system around the task. Before a branch closes or an agent reports completion, require a short record: intended disposition, evidence, risk class, required approver, maintenance owner and cleanup action. The form can be tiny for low-risk work and stricter when consequences grow.
Some organisations require review for every change. That policy decides the route even when a patch looks trivial. Some teams use trunk-based development, pairing or automated deployment without long-lived branches. They still make the same decision through pre-merge approval, feature flags, change records or rollback rules. The method is about explicit disposition, not one Git ritual.
I value the pause because it separates curiosity from commitment. An experiment can teach without becoming an obligation. A production change can move quickly without pretending that speed removes responsibility. Finished should mean the work has evidence, an owner and a chosen destination, including the honest destination of nowhere.