| name | git-coding |
| description | (💛) Core guidelines for interacting with git repositories, updating CHANGELOGs, and safely bumping versions. Use this skill whenever proposing or executing git commits, pushing code, or making destructive file changes. |
| compatibility | Gemini CLI |
| metadata | {"version":"0.0.2"} |
Git Coding Best Practices
Overview
This skill provides the mandatory guidelines for executing git operations, ensuring safe repository management, and correctly formatting commits and releases.
Core Mandates
1. No Destructive Commands
NEVER use destructive git commands such as git clean -fd, git reset --hard, or git push --force.
Untracked files may contain active, uncommitted work by the user or other agents.
- Rule of Thumb: If you need to revert or clean up, only use surgical
rm commands on the exact files you created. If you are unsure about untracked files, always ask the user before deleting them.
2. The Pre-Commit Checklist
Before proposing or executing any git commit, you must perform the following two actions in the repository:
- Bump Version: Find the main configuration file containing the version (e.g.,
gemini-extension.json, package.json, etc.) and increment it according to Semantic Versioning (usually a patch bump, like 0.1.4 -> 0.1.5).
- Update CHANGELOG.md: Add a new entry to the
CHANGELOG.md file documenting the changes under the new version header. Follow the [Keep a Changelog] format.
3. Commit Message Formatting
- Start by gathering context:
git status, git diff HEAD, and git log -n 3 to match the existing commit style.
- Prefer commit messages that are clear, concise, and focused more on "why" than "what".
- If the repository uses
gitmoji, use the appropriate emoji in the commit title (e.g., 🐛 for bugs, ✨ for features, chore, etc.).
4. Push Etiquette
- NEVER push changes to a remote repository automatically unless explicitly requested by the user.
5. Renaming
- prefer
git mv to mv if file is under version control.
Workflow Example
When asked to "commit the recent changes":
- Check
git status and git diff.
- Find the version file and bump it.
- Add the changes to
CHANGELOG.md.
- Stage the files (
git add ...).
- Propose the commit message to the user or execute it if given permission.
- Ensure to attach GH issue if available the messages. If so also comment on the issue post-commit/push with a digest of what has been done. It reads nicely.
