Atomic Commits
This skill guides the process of creating atomic git commits from an existing changeset.
Core Principle
"The goal is that every commit just works - so you need to commit features in a non-breaking, incremental way."
Workflow
- •
Analyze Changes
- •Examine the current status with
git status. - •Review diffs with
git diffto understand all pending changes.
- •Examine the current status with
- •
Plan Atomic Commits
- •Group changes into logical units.
- •Rule: Dependencies must be committed before dependents.
- •Rule: Each commit must be self-contained and non-breaking.
- •Rule: Tests (if present and relevant) should ideally pass after each commit.
- •
Execute
- •Stage specific files or hunks using
git add(orgit add -pfor partial file staging). - •Commit with a clear, descriptive message explaining why the change was made, not just what changed.
- •Repeat until the working directory is clean (or only contains changes meant for a later batch).
- •Stage specific files or hunks using
Example Scenario
Context: You have modified a backend API, updated the frontend to use the new API, and added a new dependency in package.json.
Bad Approach: git commit -am "update api and frontend" (Too large, mixes concerns).
Atomic Approach:
- •
git add package.json package-lock.json-> Commit: "Addaxiosdependency" (Safe, pre-requisite). - •
git add backend/api.py-> Commit: "Update API endpoint to support user filtering" (Backend works independently). - •
git add frontend/UserList.js-> Commit: "Connect frontend to new user filtering API" (Frontend uses the now-available API).