Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
hyperb1iss avatar

Git

  • 30 installs
  • 25 repo stars
  • Updated July 31, 2026
  • hyperb1iss/hyperskills

Handles complex git operations: rebases, merge-conflict resolution, cherry-picking, bisect, worktrees, and repository archaeology.

About

Covers advanced git workflows and conflict-resolution strategies. A developer uses it for rebases, merge conflicts, cherry-picks, bisect, or repository history work.

  • Conflict-resolution decision tree by file type
  • Lock-file and SOPS conflicts regenerated, never merged manually

Git by the numbers

  • 30 all-time installs (skills.sh)
  • +1 installs in the week ending Aug 2, 2026 (Skillselion tracking)
  • Ranked #360 of 733 Git & Pull Requests skills by installs in the Skillselion catalog
  • Data as of Aug 2, 2026 (Skillselion catalog sync)
npx skills add https://github.com/hyperb1iss/hyperskills --skill git

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs30
repo stars25
Last updatedJuly 31, 2026
Repositoryhyperb1iss/hyperskills

What it does

Handles complex git operations: rebases, merge-conflict resolution, cherry-picking, bisect, worktrees, and repository archaeology.

Files

SKILL.mdMarkdownGitHub ↗

Git Operations

Advanced git workflows and conflict resolution.

Decision Trees

Conflict Resolution Strategy

SituationStrategy
Lock file conflict (pnpm-lock, Cargo.lock, etc.)Never merge manually. Checkout theirs, regenerate.
SOPS encrypted fileCheckout theirs, run sops updatekeys, re-add.
Simple content conflictResolve manually, prefer smallest diff.
Large structural conflictConsider --ours/--theirs + manual reapply of the smaller side.

Rebase vs Merge

SituationUse
Feature branch behind maingit rebase origin/main
Shared branch (others have it checked out)Never rebase. Merge only.
Cleaning up messy commits before PRgit rebase -i with squash/fixup
Already pushed and others pulledNever rebase. Use git revert instead.

Undo Operations

What happenedFix
Wrong commit message (not pushed)git commit --amend
Last commit was wrong (keep changes staged)git reset --soft HEAD~1
Last commit was wrong (keep changes unstaged)git reset HEAD~1
Already pushed bad commitgit revert <hash> (creates new commit)
Need to recover something lostgit reflog then git checkout HEAD@{N}

Lock File Conflicts

Always regenerate, never manually merge:

# pnpm
git checkout --theirs pnpm-lock.yaml && pnpm install && git add pnpm-lock.yaml

# npm
git checkout --theirs package-lock.json && npm install && git add package-lock.json

# Cargo
git checkout --theirs Cargo.lock && cargo generate-lockfile && git add Cargo.lock

# SOPS encrypted files
git checkout --theirs secrets.yaml && sops updatekeys secrets.yaml && git add secrets.yaml

Verify Before You Trust

Regenerating or rebasing is not the same as verifying the result. In a concurrent monorepo, prove it.

Clean-room lockfile check -- after a rebase that touches a lockfile, regenerate in a throwaway worktree and byte-diff before trusting the auto-regen (lockfile tooling silently drops importers mid-rebase):

git worktree add /tmp/lockcheck HEAD
(cd /tmp/lockcheck && pnpm install --lockfile-only)
diff -q /tmp/lockcheck/pnpm-lock.yaml ./pnpm-lock.yaml && echo "IDENTICAL to clean-room regen"
git worktree remove /tmp/lockcheck

Prove a rebase preserved intent -- range-diff shows exactly which commits changed and how:

git tag pre-rebase-$(date +%Y%m%d-%H%M%S)   # before rewriting
git rebase --onto <new-base> <old-base> <branch>
git range-diff <old-base>...<branch>         # every differing commit should be intentional

Archaeology

# Find when a string was added/removed
git log -S "search string" --oneline

# Blame specific lines
git blame -L 10,20 <file>

# Find commits touching a function
git log -L :functionName:file.js

# Binary search for a bug introduction
git bisect start && git bisect bad HEAD && git bisect good v1.0.0

Safety Rules

1. Never rebase shared branches 2. `--force-with-lease` not --force (prevents overwriting others' work) 3. Regenerate lock files -- never merge them 4. Backup branch before destructive ops: git branch backup-$(date +%Y%m%d-%H%M%S) 5. Never commit large binaries -- use Git LFS 6. Prove history rewrites -- tag the pre-rewrite head, then range-diff after a rebase to confirm every changed commit is intentional

Anti-Patterns

Anti-PatternFix
Manually merging generated lockfilesTake one side, regenerate with the package tool
Rebasing a shared branchMerge or create a new branch
Using --forceUse --force-with-lease only when approved
Running recovery commands by habitInspect status, log, and reflog first
Staging unrelated workgit add <specific-files>
git checkout <commit> -- <paths> then committingIt stages silently; check git diff --cached --name-only before each commit or it swallows unintended files
Trusting an auto-regenerated lockfileVerify in a throwaway worktree + byte-diff before relying on it
Assuming a rebase kept your commitsProve it with git range-diff <old>...<new>

What This Skill is NOT

  • Not for routine git status or simple commits.
  • Not permission to rewrite shared history.
  • Not a replacement for understanding the diff before committing.

Related skills

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.