agentleFS
VepricovVepricov/claude-brainlab/skills/git-workflow/SKILL.md

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

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 AzureSkill

    squad-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

  • harrissohail6Skill

    ci-cd-pipelines

    CI/CD pipeline design and implementation. Auto-activates when discussing deployment, automation, or pipelines.

    Also in 6 projects that use this

  • Microsoft AzureSkill

    architectural-proposals

    How to write comprehensive architectural proposals that drive alignment before code is written

    Also in 4 projects that use this

  • GitHubSkill

    e2e-template-testing

    End-to-end validation of coordinator and agent template changes

    Also in 3 projects that use this

  • GitHubSkill

    notification-routing

    Route agent notifications to specific channels by type — prevent alert fatigue from single-channel flooding

    Also in 3 projects that use this

  • frostneySkill

    native-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

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
  1. Distinctive:

    Start with a verb: add, fix, update, remove, optimize

    line 37
  2. Distinctive:

    No more than 50 characters

    line 38
  3. Distinctive:

    No period at the end

    line 39
  4. Distinctive:

    No direct pushes allowed

    line 69
  5. Distinctive:

    Must merge via Pull Request

    line 70
  6. Distinctive:

    Must pass CI checks

    line 71
  7. Very specific:

    Feature branch syncing develop: Use rebase

    line 170
  8. Very specific:

    Feature branch merging to develop: Use merge --no-ff

    line 171
  9. Very specific:

    develop merging to master: Use merge --no-ff

    line 172
  10. Very specific:

    Project convention: Use --no-ff when merging feature branches to preserve branch history.

    line 188
  11. Distinctive:

    Small commits: - Commit small changes frequently

    line 240
  12. Distinctive:

    Communication: - Avoid modifying the same file simultaneously

    line 242
  13. Distinctive:

    Security: No security vulnerabilities, sensitive information protected

    line 349
  14. Distinctive:

    Performance: No obvious performance issues, resources properly released

    line 350
  15. Distinctive:

    Follow Conventional Commits specification

    line 410
  16. Distinctive:

    Write clear commit messages describing changes

    line 411
  17. Distinctive:

    Run code checks before committing

    line 413
  18. Distinctive:

    Use feature branches for development

    line 424
  19. Distinctive:

    Delete branches promptly after feature completion

    line 426
  20. Very specific:

    Use --no-ff merge to preserve history

    line 427
  21. Distinctive:

    All code goes through Pull Requests

    line 438
  22. Very specific:

    references/commit-conventions.md: - Commit message detailed conventions and examples

    line 452
  23. Distinctive:

    Commit Messages: - Follow Conventional Commits specification

    line 470
  24. Very specific:

    Merge Strategy: - Use rebase to sync feature branches, merge --no-ff to merge

    line 473

“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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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

TypeDescriptionExample
featNew featurefeat(user): add user export functionality
fixBug fixfix(login): fix captcha not refreshing
docsDocumentation updatedocs(api): update API documentation
refactorRefactoringrefactor(utils): refactor utility functions
perfPerformance improvementperf(list): optimize list performance
testTest relatedtest(user): add unit tests
choreOther changeschore: 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 TypeNaming ConventionDescriptionLifecycle
mastermasterMain branch, releasable statePermanent
developdevelopDevelopment branch, latest integrated codePermanent
featurefeature/feature-nameFeature branchDelete after completion
bugfixbugfix/issue-descriptionBug fix branchDelete after fix
hotfixhotfix/issue-descriptionEmergency fix branchDelete after fix
releaserelease/version-numberRelease branchDelete 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 release

Branch 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-management

Hotfix 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 develop

Release 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 develop

Merge Strategy

Merge vs Rebase

FeatureMergeRebase
HistoryPreserves complete historyLinear history
Use casePublic branchesPrivate branches
Recommended forMerging to main branchSyncing 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 operation

Project 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-management

Resolving 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 conflict

Conflict 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 --abort

Preventing Conflicts

  1. Sync code regularly - Pull latest code before starting work each day
  2. Small commits - Commit small changes frequently
  3. Modular features - Implement different features in different files
  4. 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
!.gitkeep

Common .gitignore

node_modules/
dist/
build/
.idea/
.vscode/
.env
.env.local
logs/
*.log
.DS_Store
Thumbs.db

For 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.0

Team 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 updated

Code 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 master

Rollback to Previous Version

# Reset to specific commit (discards subsequent commits)
git reset --hard abc123

# Create reverse commit (recommended, preserves history)
git revert abc123

Stash Current Work

git stash save "work in progress"
git stash list
git stash pop

View File Modification History

git log -- <file>             # Commit history
git log -p -- <file>          # Detailed content
git blame <file>              # Per-line author

Best 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-ff merge 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 examples
  • references/branching-strategies.md - Comprehensive branch management strategies
  • references/merge-strategies.md - Merge, rebase, and conflict resolution strategies
  • references/conflict-resolution.md - Detailed conflict handling and prevention
  • references/advanced-usage.md - Git performance optimization, security, submodules, and advanced techniques
  • references/collaboration.md - Pull request and code review guidelines
  • references/gitignore-guide.md - .gitignore patterns and project-specific configurations

Example Files

Working examples in examples/:

  • examples/commit-messages.txt - Good commit message examples
  • examples/workflow-commands.sh - Common workflow command snippets

Summary

This document defines the project's Git standards:

  1. Commit Messages - Follow Conventional Commits specification
  2. Branch Management - master/develop/feature/bugfix/hotfix/release branch strategy
  3. Workflows - Standard processes for daily development, hotfixes, and releases
  4. Merge Strategy - Use rebase to sync feature branches, merge --no-ff to merge
  5. Tag Management - Semantic versioning, annotated tags
  6. Conflict Resolution - Regular syncing, small commits, team communication

Following these standards improves collaboration efficiency, ensures code quality, and simplifies version management.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.