
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 gitAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 30 |
|---|---|
| repo stars | ★ 25 |
| Last updated | July 31, 2026 |
| Repository | hyperb1iss/hyperskills ↗ |
What it does
Handles complex git operations: rebases, merge-conflict resolution, cherry-picking, bisect, worktrees, and repository archaeology.
Files
Git Operations
Advanced git workflows and conflict resolution.
Decision Trees
Conflict Resolution Strategy
| Situation | Strategy |
|---|---|
| Lock file conflict (pnpm-lock, Cargo.lock, etc.) | Never merge manually. Checkout theirs, regenerate. |
| SOPS encrypted file | Checkout theirs, run sops updatekeys, re-add. |
| Simple content conflict | Resolve manually, prefer smallest diff. |
| Large structural conflict | Consider --ours/--theirs + manual reapply of the smaller side. |
Rebase vs Merge
| Situation | Use |
|---|---|
| Feature branch behind main | git rebase origin/main |
| Shared branch (others have it checked out) | Never rebase. Merge only. |
| Cleaning up messy commits before PR | git rebase -i with squash/fixup |
| Already pushed and others pulled | Never rebase. Use git revert instead. |
Undo Operations
| What happened | Fix |
|---|---|
| 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 commit | git revert <hash> (creates new commit) |
| Need to recover something lost | git 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.yamlVerify 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/lockcheckProve 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 intentionalArchaeology
# 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.0Safety 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-Pattern | Fix |
|---|---|
| Manually merging generated lockfiles | Take one side, regenerate with the package tool |
| Rebasing a shared branch | Merge or create a new branch |
Using --force | Use --force-with-lease only when approved |
| Running recovery commands by habit | Inspect status, log, and reflog first |
| Staging unrelated work | git add <specific-files> |
git checkout <commit> -- <paths> then committing | It stages silently; check git diff --cached --name-only before each commit or it swallows unintended files |
| Trusting an auto-regenerated lockfile | Verify in a throwaway worktree + byte-diff before relying on it |
| Assuming a rebase kept your commits | Prove it with git range-diff <old>...<new> |
What This Skill is NOT
- Not for routine
git statusor simple commits. - Not permission to rewrite shared history.
- Not a replacement for understanding the diff before committing.