git
Guide for using git according to my preferences. Use it when you're asked to commit something.
When & Why to Use This Skill
This Claude skill streamlines Git workflows by enforcing personalized branch naming conventions and standardized commit message formatting. It enhances repository maintainability by ensuring consistent code identifier referencing, specifically optimized for Go projects, and automates GitHub issue tracking through precise message syntax.
Use Cases
- Standardizing branch creation: Automatically naming branches using short, dash-separated sentences to maintain a clean and readable repository structure.
- Consistent commit documentation: Enforcing the use of backticks for code identifiers and including package names for Go structs and methods to improve code searchability.
- Automated GitHub issue management: Correctly formatting 'Fixes #123' syntax in commit messages to ensure GitHub automatically closes linked issues upon merging.
- Workflow optimization: Following specific rules for commit amends and simplified messaging on feature branches to facilitate cleaner squash-merge operations.
| name | git |
|---|---|
| description | Guide for using git according to my preferences. Use it when you're asked to commit something. |
| license | MIT |
git
Most of git usage is what you already know, so depend on that. This is skill is just a refinement.
Branch naming
Just name the branch a short sentence seperated with dashes. Example: add-some-feature. Don't use feat/, hotfix/ etc. prefixes.
Commit messages
- Always enclose code identifiers with backticks. Example: "Add
html.UserPagecomponent" - Always refer to Go code identifiers including the package name, like in
html.UserPageabove. Fields and methods on structs can be referred withmodel.User.Name. - Ask me about any Github issues that should be referenced. Reference them at the end of the commit message like this: "See #123, #234". If the commit fixes one or more issues, use "Fixes #123, fixes #234" instead (the double "fixes" is important for Github to actually close the issue).
- Don't mention that you've updated tests, that's assumed.
Committing
- Don't amend previous commits unless instructed to. When committing after the first commit on a branch, just commit with a simple message (e.g. "fixing …"), because the branch will most times be squashed on Github anyway.