git-coding

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:

1. 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).
2. 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":

1. Check git status and git diff.
2. Find the version file and bump it.
3. Add the changes to CHANGELOG.md.
4. Stage the files (git add ...).
5. Propose the commit message to the user or execute it if given permission.
6. 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.