agentleFS
tsukhanitsukhani/jclaw/skills/git/SKILL.md

git

Skill42 starsChanged 7 days agoMITView on GitHub

Git commits, branches, rebases, merges, conflict resolution, history recovery, team workflows, and safe day-to-day version control.

  • Deletes or force-pushes
  • Commits and pushes

57 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use sql, databases 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.
  • thechandanbhagatSkill

    sql

    Write SQL queries, optimize database performance, design schemas, and debug SQL issues. Use for database operations, query optimization, and schema design.

    Also in 4 projects that use this

  • mrgoonieSkill

    databases

    Work with MongoDB (document database, BSON documents, aggregation pipelines, Atlas cloud) and PostgreSQL (relational database, SQL queries, psql CLI, pgAdmin). Use when designing database schemas, writing queries and aggregations, optimizing indexes for performance, performing database migrations, configuring replication and sharding, implementing backup and restore strategies, managing database users and permissions, analyzing query performance, or administering production databases.

    Also in 3 projects that use this

  • mrgoonieSkill

    devops

    Deploy to Cloudflare (Workers, R2, D1), Docker, GCP (Cloud Run, GKE), Kubernetes (kubectl, Helm). Use for serverless, containers, CI/CD, GitOps, security audit.

    Also in 4 projects that use this

  • MicrosoftSkill

    typescript

    TypeScript best practices for this monorepo. Use this skill when: (1) writing new TypeScript code, (2) reviewing TypeScript code, (3) working with API responses, fetch calls, or JSON parsing, (4) adding or modifying types and interfaces.

    Also in 4 projects that use this

  • VercelSkill

    react

    React renderer for json-render that turns JSON specs into React components. Use when working with @json-render/react, building React UIs from JSON, creating component catalogs, or rendering AI-generated specs.

    Also in 3 projects that use this

  • Microsoft AzureSkill

    test

    Also in 8 projects that use this

The file

Show its rules and text

We split this skill into the rules it gives an agent

14 rules. 0 are common, 10 are distinctive, and 4 are very specific to this project.

  • 0

    Common

    Most of the 51 edited versions we read keep these.

  • 10

    Distinctive

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Distinctive:

    Use when the task involves Git repositories, branches, commits, merges, rebases, pull requests, conflict resolution, history inspection, or …

    line 13
  2. Very specific:

    Use conventional commit format: type(scope): description

    line 57
  3. Distinctive:

    Keep first line under 72 characters

    line 58
  4. Very specific:

    Use git push --force-with-lease instead of --force — prevents overwriting others' work

    line 63
  5. Distinctive:

    If push rejected, run git pull --rebase before retrying

    line 64
  6. Distinctive:

    Never force push to main/master branch

    line 65
  7. Very specific:

    After editing conflicted files, verify no markers remain: grep -r "<<<\|>>>\|===" .

    line 69
  8. Distinctive:

    Test that code builds before completing merge

    line 70
  9. Distinctive:

    If merge becomes complex, abort with git merge --abort and try git rebase instead

    line 71
  10. Distinctive:

    Delete merged branches locally: git branch -d branch-name

    line 75
  11. Distinctive:

    Before creating PR, rebase feature branch onto latest main

    line 77
  12. Distinctive:

    Use git rebase -i to squash messy commits before pushing

    line 78
  13. Very specific:

    Before destructive operations (reset --hard, rebase, force push):

    line 82
  14. Distinctive:

    Use git add -p for partial staging when commit mixes multiple changes

    line 106

“Common” is measured: kept by at least 6 in 10 of the 51 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

When to Use

Use when the task involves Git repositories, branches, commits, merges, rebases, pull requests, conflict resolution, history inspection, or recovery. This skill is stateless and should be applied by default whenever Git work is part of the job.

Quick Reference

TopicFile
Essential commandscommands.md
Advanced operationsadvanced.md
Branch strategiesbranching.md
Conflict resolutionconflicts.md
History and recoveryhistory.md
Team workflowscollaboration.md

Core Rules

  1. Never force push to shared branches — Use --force-with-lease on feature branches only
  2. Commit early, commit often — Small commits are easier to review, revert, and bisect
  3. Write meaningful commit messages — First line under 72 chars, imperative mood
  4. Pull before push — Always git pull --rebase before pushing to avoid merge commits
  5. Clean up before merging — Use git rebase -i to squash fixup commits

Team Workflows

Feature Branch Flow:

  1. git checkout -b feature/name from main
  2. Make commits, push regularly
  3. Open PR, get review
  4. Squash and merge to main
  5. Delete feature branch

Hotfix Flow:

  1. git checkout -b hotfix/issue from main
  2. Fix, test, commit
  3. Merge to main AND develop (if exists)
  4. Tag the release

Daily Sync:

git fetch --all --prune
git rebase origin/main  # or merge if team prefers

Commit Messages

  • Use conventional commit format: type(scope): description
  • Keep first line under 72 characters
  • Types: feat, fix, docs, style, refactor, test, chore

Push Safety

  • Use git push --force-with-lease instead of --force — prevents overwriting others' work
  • If push rejected, run git pull --rebase before retrying
  • Never force push to main/master branch

Conflict Resolution

  • After editing conflicted files, verify no markers remain: grep -r "<<<\|>>>\|===" .
  • Test that code builds before completing merge
  • If merge becomes complex, abort with git merge --abort and try git rebase instead

Branch Hygiene

  • Delete merged branches locally: git branch -d branch-name
  • Clean remote tracking: git fetch --prune
  • Before creating PR, rebase feature branch onto latest main
  • Use git rebase -i to squash messy commits before pushing

Safety Checklist

Before destructive operations (reset --hard, rebase, force push):

  • Is this a shared branch? → Don't rewrite history
  • Do I have uncommitted changes? → Stash or commit first
  • Am I on the right branch? → git branch to verify
  • Is remote up to date? → git fetch first

Common Traps

  • git user.email wrong — Verify with git config user.email before important commits
  • Empty directories — Git doesn't track them, add .gitkeep
  • Submodules — Always clone with --recurse-submodules
  • Detached HEAD — Use git switch - to return to previous branch
  • Push rejected — Usually needs git pull --rebase first
  • stash pop on conflict — Stash disappears. Use stash apply instead
  • Large files — Use Git LFS for files >50MB, never commit secrets
  • Case sensitivity — Mac/Windows ignore case, Linux doesn't — causes CI failures

Recovery Commands

  • Undo last commit keeping changes: git reset --soft HEAD~1
  • Discard unstaged changes: git restore filename
  • Find lost commits: git reflog (keeps ~90 days of history)
  • Recover deleted branch: git checkout -b branch-name <sha-from-reflog>
  • Use git add -p for partial staging when commit mixes multiple changes

Debugging with Bisect

Find the commit that introduced a bug:

git bisect start
git bisect bad                    # current commit is broken
git bisect good v1.0.0            # this version worked
# Git checks out middle commit, test it, then:
git bisect good                   # or git bisect bad
# Repeat until Git finds the culprit
git bisect reset                  # return to original branch

Quick Summary

git status -sb                    # short status with branch
git log --oneline -5              # last 5 commits
git shortlog -sn                  # contributors by commit count
git diff --stat HEAD~5            # changes summary last 5 commits
git branch -vv                    # branches with tracking info
git stash list                    # pending stashes

Related Skills

Install with clawhub install <slug> if user confirms:

  • gitlab — GitLab CI/CD and merge requests
  • docker — Containerization workflows
  • code — Code quality and best practices

Feedback

  • If useful: clawhub star git
  • Stay updated: clawhub sync

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.