git-workflow
Skill35 starsChanged 2 months agoMITView on GitHub
Prepares commits, branches and pull requests following the repository's existing Git conventions, including Conventional Commits messages and merge strategy. Use when the user asks to write a commit message, name or create a branch, open a pull request, or asks how to handle merges in this project.
- Reads credentials
- Deletes or force-pushes
- Commits and pushes
188 other projects use a version of this, 2 of them edited.
Adopted by
Most recently taken up by
- Rojios/everything-claude-codetheir own version, first seen Nov 8, 2026
- kinhluan/skillstheir own version, first seen Nov 8, 2026
- juninmd/skillstheir own version, first seen Nov 8, 2026
- jDxve/avengers-kittheir own version, first seen Nov 8, 2026
- lhbsaa/apex-unifiedtheir own version, first seen Nov 8, 2026
- haythamasalama/skillstheir own version, first seen Nov 8, 2026
Used with
Projects with it also use squad-commands, ci-cd-pipelines and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
Microsoft AzureSkillsquad-commands
Categorized catalog of common Squad operations. Coordinator reads this file and presents it as an interactive menu when the user asks for available commands or help.
Also in 5 projects that use this
harrissohail6Skillci-cd-pipelines
CI/CD pipeline design and implementation. Auto-activates when discussing deployment, automation, or pipelines.
Also in 6 projects that use this
Microsoft AzureSkillarchitectural-proposals
How to write comprehensive architectural proposals that drive alignment before code is written
Also in 4 projects that use this
GitHubSkille2e-template-testing
End-to-end validation of coordinator and agent template changes
Also in 3 projects that use this
GitHubSkillnotification-routing
Route agent notifications to specific channels by type — prevent alert fatigue from single-channel flooding
Also in 3 projects that use this
frostneySkillnative-nostalgia-stack
Applies the user's FreePascal toolchain and its build, formatting, hook, and test contracts while leaving project-specific mechanics local. Use when scaffolding or working in a FreePascal project that follows this toolchain.
Also in 3 projects that use this
- +5 more from Azure
- +1 more from github
Other versions188 projects use a version of this.
Word for word · 1
- shkodnik1917/claude-brainlab★ 35100% same
Edited · 2
- Galaxy-Dawn/claude-scholar★ 5.9k97% same
- Clay-HHK/claude-skills★ 197% same
Wrote their own version · 185
- langfuse/langfuse★ 37ksame name
- modelcontextprotocol/typescript-sdk★ 14ksame name
- JetBrains/ideavim★ 10ksame name
- jokob-sk/NetAlertX★ 7.4ksame name
- netalertx/NetAlertX★ 7.4ksame name
- github/gh-aw★ 5.6ksame name
- modelcontextprotocol/csharp-sdk★ 4.6ksame name
- antonbabenko/pre-commit-terraform★ 3.8ksame name
- github/squad★ 3.4ksame name
- jd-opensource/xllm★ 1.6ksame name
175 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository68 other files it gives its agents.
- rules/agents.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- academic-plottingSkill
- agent-identifierSkill
- architecture-designSkill
- astar-paper-reviewSkill
- bug-detectiveSkill
- call-notesSkill
- cavemanSkill
- citation-verificationSkill
- code-ingestSkill
- code-librarySkill
- code-review-excellenceSkill
- command-developmentSkill
- create-projectSkill
- daily-codingSkill
- defuddleSkill
- diagnoseSkill
- doc-coauthoringSkill
- experiment-runsSkill
- frontend-designSkill
- git-guardrails-claude-codeSkill
- google-workspace-mcpSkill
- grill-meSkill
- grill-with-docsSkill
- handoffSkill
- handoff-to-jarvisSkill
- hook-developmentSkill
- improve-codebase-architectureSkill
- json-canvasSkill
- kaggle-learnerSkill
- lab-knowledgeSkill
- latex-conference-template-organizerSkill
- mcp-integrationSkill
- ml-paper-writingSkill
- obsidian-basesSkill
- obsidian-cliSkill
- obsidian-experiment-logSkill
- obsidian-markdownSkill
- operon-obsidian-setupSkill
- paper-ingestSkill
- paper-searchSkill
- paper-to-socialSkill
- paper-venue-formattingSkill
- pdf-readerSkill
- planning-with-filesSkill
- plugin-structureSkill
- presentationSkill
- presenter-modeSkill
- prototypeSkill
- research-cycleSkill
- research-ideationSkill
- restore-sessionSkill
- results-analysisSkill
- results-reportSkill
- reverse-outline-flow-checkSkill
- review-responseSkill
- setup-pre-commitSkill
- skill-developmentSkill
- tddSkill
- The first 60 shown.
The file
Show its rules and text
We split this skill into the rules it gives an agent
24 rules. 0 are common, 17 are distinctive, and 7 are very specific to this project.
0
Common
Most of the 164 edited versions we read keep these.
17
Distinctive
This author's own choices. Worth a look.
7
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 37
Start with a verb: add, fix, update, remove, optimize
- Distinctive: line 38
No more than 50 characters
- Distinctive: line 39
No period at the end
- Distinctive: line 69
No direct pushes allowed
- Distinctive: line 70
Must merge via Pull Request
- Distinctive: line 71
Must pass CI checks
- Very specific: line 170
Feature branch syncing develop: Use rebase
- Very specific: line 171
Feature branch merging to develop: Use merge --no-ff
- Very specific: line 172
develop merging to master: Use merge --no-ff
- Very specific: line 188
Project convention: Use --no-ff when merging feature branches to preserve branch history.
- Distinctive: line 240
Small commits: - Commit small changes frequently
- Distinctive: line 242
Communication: - Avoid modifying the same file simultaneously
- Distinctive: line 349
Security: No security vulnerabilities, sensitive information protected
- Distinctive: line 350
Performance: No obvious performance issues, resources properly released
- Distinctive: line 410
Follow Conventional Commits specification
- Distinctive: line 411
Write clear commit messages describing changes
- Distinctive: line 413
Run code checks before committing
- Distinctive: line 424
Use feature branches for development
- Distinctive: line 426
Delete branches promptly after feature completion
- Very specific: line 427
Use --no-ff merge to preserve history
- Distinctive: line 438
All code goes through Pull Requests
- Very specific: line 452
references/commit-conventions.md: - Commit message detailed conventions and examples - Distinctive: line 470
Commit Messages: - Follow Conventional Commits specification
- Very specific: line 473
Merge Strategy: - Use rebase to sync feature branches, merge --no-ff to merge
“Common” is measured: kept by at least 6 in 10 of the 164 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Git Workflow Standards
This document defines the project's Git usage standards, including commit message format, branch management strategy, workflows, merge strategies, and more. Following these standards improves collaboration efficiency, enables traceability, supports automation, and reduces conflicts.
Commit Message Standards
The project follows the Conventional Commits specification:
<type>(<scope>): <subject>
<body>
<footer>Type Reference
| Type | Description | Example |
feat | New feature | feat(user): add user export functionality |
fix | Bug fix | fix(login): fix captcha not refreshing |
docs | Documentation update | docs(api): update API documentation |
refactor | Refactoring | refactor(utils): refactor utility functions |
perf | Performance improvement | perf(list): optimize list performance |
test | Test related | test(user): add unit tests |
chore | Other changes | chore: update dependency versions |
Subject Rules
- Start with a verb: add, fix, update, remove, optimize
- No more than 50 characters
- No period at the end
For more detailed conventions and examples, see references/commit-conventions.md.
Branch Management Strategy
Branch Types
| Branch Type | Naming Convention | Description | Lifecycle |
| master | master | Main branch, releasable state | Permanent |
| develop | develop | Development branch, latest integrated code | Permanent |
| feature | feature/feature-name | Feature branch | Delete after completion |
| bugfix | bugfix/issue-description | Bug fix branch | Delete after fix |
| hotfix | hotfix/issue-description | Emergency fix branch | Delete after fix |
| release | release/version-number | Release branch | Delete after release |
Branch Naming Examples
feature/user-management # User management feature
feature/123-add-export # Issue-linked feature
bugfix/login-error # Login error fix
hotfix/security-vulnerability # Security vulnerability fix
release/v1.0.0 # Version releaseBranch Protection Rules
master branch:
- No direct pushes allowed
- Must merge via Pull Request
- Must pass CI checks
- Requires at least one Code Review approval
develop branch:
- Direct pushes restricted
- Pull Request merges recommended
- Must pass CI checks
For detailed branch strategies and workflows, see references/branching-strategies.md.
Workflows
Daily Development Workflow
# 1. Sync latest code
git checkout develop
git pull origin develop
# 2. Create feature branch
git checkout -b feature/user-management
# 3. Develop and commit
git add .
git commit -m "feat(user): add user list page"
# 4. Push to remote
git push -u origin feature/user-management
# 5. Create Pull Request and request Code Review
# 6. Merge to develop (via PR)
# 7. Delete feature branch
git branch -d feature/user-management
git push origin -d feature/user-managementHotfix Workflow
# 1. Create fix branch from master
git checkout master
git pull origin master
git checkout -b hotfix/critical-bug
# 2. Fix and commit
git add .
git commit -m "fix(auth): fix authentication bypass vulnerability"
# 3. Merge to master
git checkout master
git merge --no-ff hotfix/critical-bug
git tag -a v1.0.1 -m "hotfix: fix authentication bypass vulnerability"
git push origin master --tags
# 4. Sync to develop
git checkout develop
git merge --no-ff hotfix/critical-bug
git push origin developRelease Workflow
# 1. Create release branch
git checkout develop
git checkout -b release/v1.0.0
# 2. Update version numbers and documentation
# 3. Commit version update
git add .
git commit -m "chore(release): prepare release v1.0.0"
# 4. Merge to master
git checkout master
git merge --no-ff release/v1.0.0
git tag -a v1.0.0 -m "release: v1.0.0 official release"
git push origin master --tags
# 5. Sync to develop
git checkout develop
git merge --no-ff release/v1.0.0
git push origin developMerge Strategy
Merge vs Rebase
| Feature | Merge | Rebase |
| History | Preserves complete history | Linear history |
| Use case | Public branches | Private branches |
| Recommended for | Merging to main branch | Syncing upstream code |
Recommendations
- Feature branch syncing develop: Use
rebase - Feature branch merging to develop: Use
merge --no-ff - develop merging to master: Use
merge --no-ff
# ✅ Recommended: Feature branch syncing develop
git checkout feature/user-management
git rebase develop
# ✅ Recommended: Merge feature branch to develop
git checkout develop
git merge --no-ff feature/user-management
# ❌ Not recommended: Rebase on public branch
git checkout develop
git rebase feature/xxx # Dangerous operationProject convention: Use --no-ff when merging feature branches to preserve branch history.
For detailed merge strategies and techniques, see references/merge-strategies.md.
Conflict Resolution
Identifying Conflicts
<<<<<<< HEAD
// Current branch code
const name = 'Alice'
=======
// Branch being merged
const name = 'Bob'
>>>>>>> feature/user-managementResolving Conflicts
# 1. View conflicting files
git status
# 2. Manually edit files to resolve conflicts
# 3. Mark as resolved
git add <file>
# 4. Complete the merge
git commit # merge conflict
# or
git rebase --continue # rebase conflictConflict Resolution Strategies
# Keep current branch version
git checkout --ours <file>
# Keep incoming branch version
git checkout --theirs <file>
# Abort merge
git merge --abort
git rebase --abortPreventing Conflicts
- Sync code regularly - Pull latest code before starting work each day
- Small commits - Commit small changes frequently
- Modular features - Implement different features in different files
- Communication - Avoid modifying the same file simultaneously
For detailed conflict handling and advanced techniques, see references/conflict-resolution.md.
.gitignore Standards
Basic Rules
# Ignore all .log files
*.log
# Ignore directories
node_modules/
# Ignore directory at root
/temp/
# Ignore files in all directories
**/.env
# Don't ignore specific files
!.gitkeepCommon .gitignore
node_modules/
dist/
build/
.idea/
.vscode/
.env
.env.local
logs/
*.log
.DS_Store
Thumbs.dbFor detailed .gitignore patterns and project-specific configurations, see references/gitignore-guide.md.
Tag Management
Uses Semantic Versioning:
MAJOR.MINOR.PATCH[-PRERELEASE]Version Change Rules
- MAJOR: Incompatible API changes (v1.0.0 → v2.0.0)
- MINOR: Backward-compatible new features (v1.0.0 → v1.1.0)
- PATCH: Backward-compatible bug fixes (v1.0.0 → v1.0.1)
Tag Operations
# Create annotated tag (recommended)
git tag -a v1.0.0 -m "release: v1.0.0 official release"
# Push tags
git push origin v1.0.0
git push origin --tags
# View tags
git tag
git show v1.0.0
# Delete tag
git tag -d v1.0.0
git push origin :refs/tags/v1.0.0Team Collaboration Standards
Pull Request Standards
PRs should include:
## Change Description
<!-- Describe the content and purpose of this change -->
## Change Type
- [ ] New feature (feat)
- [ ] Bug fix (fix)
- [ ] Code refactoring (refactor)
## Testing Method
<!-- Describe how to test -->
## Related Issue
Closes #xxx
## Checklist
- [ ] Code has been self-tested
- [ ] Documentation has been updatedCode Review Standards
Review focus areas:
- Code quality: Clear and readable, proper naming, no duplicate code
- Logic correctness: Business logic correct, edge cases handled
- Security: No security vulnerabilities, sensitive information protected
- Performance: No obvious performance issues, resources properly released
For detailed collaboration standards and best practices, see references/collaboration.md.
Common Issues
Amending the Last Commit
# Amend commit content (not yet pushed)
git add forgotten-file.ts
git commit --amend --no-edit
# Amend commit message
git commit --amend -m "new commit message"Push Rejected
# Pull then push
git pull origin master
git push origin master
# Use rebase for cleaner history
git pull --rebase origin master
git push origin masterRollback to Previous Version
# Reset to specific commit (discards subsequent commits)
git reset --hard abc123
# Create reverse commit (recommended, preserves history)
git revert abc123Stash Current Work
git stash save "work in progress"
git stash list
git stash popView File Modification History
git log -- <file> # Commit history
git log -p -- <file> # Detailed content
git blame <file> # Per-line authorBest Practices Summary
Commit Standards
✅ Recommended:
- Follow Conventional Commits specification
- Write clear commit messages describing changes
- One commit for one logical change
- Run code checks before committing
❌ Prohibited:
- Vague commit messages
- Multiple unrelated changes in one commit
- Committing sensitive information (passwords, keys)
- Developing directly on main branch
Branch Management
✅ Recommended:
- Use feature branches for development
- Regularly sync main branch code
- Delete branches promptly after feature completion
- Use
--no-ffmerge to preserve history
❌ Prohibited:
- Developing directly on main branch
- Long-lived unmerged feature branches
- Non-standard branch naming
- Rebasing on public branches
Code Review
✅ Recommended:
- All code goes through Pull Requests
- At least one reviewer approval before merging
- Provide constructive feedback
❌ Prohibited:
- Merging without review
- Reviewing your own code
Additional Resources
Reference Files
For detailed guidance on specific topics:
references/commit-conventions.md- Commit message detailed conventions and examplesreferences/branching-strategies.md- Comprehensive branch management strategiesreferences/merge-strategies.md- Merge, rebase, and conflict resolution strategiesreferences/conflict-resolution.md- Detailed conflict handling and preventionreferences/advanced-usage.md- Git performance optimization, security, submodules, and advanced techniquesreferences/collaboration.md- Pull request and code review guidelinesreferences/gitignore-guide.md- .gitignore patterns and project-specific configurations
Example Files
Working examples in examples/:
examples/commit-messages.txt- Good commit message examplesexamples/workflow-commands.sh- Common workflow command snippets
Summary
This document defines the project's Git standards:
- Commit Messages - Follow Conventional Commits specification
- Branch Management - master/develop/feature/bugfix/hotfix/release branch strategy
- Workflows - Standard processes for daily development, hotfixes, and releases
- Merge Strategy - Use rebase to sync feature branches, merge --no-ff to merge
- Tag Management - Semantic versioning, annotated tags
- Conflict Resolution - Regular syncing, small commits, team communication
Following these standards improves collaboration efficiency, ensures code quality, and simplifies version management.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

