getty-git-usage

Guides rebasing, committing, and landing branches with linear Git history.

1|Updated Mar 29, 2026
One-click install
npx skills add https://github.com/Getty/p5-alien-libssh --skill getty-git-usage-getty
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: getty-git-usage
Source: https://github.com/Getty/p5-alien-libssh/tree/main/.claude/skills/getty-git-usage
Command: npx skills add https://github.com/Getty/p5-alien-libssh --skill getty-git-usage-getty

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams lose the ability to bisect, revert, and cherry-pick when work lands as squashed lumps or merge-heavy histories. This Skill enforces a consistent Git workflow — rebase over merge, small frequent commits, and conventional commit prefixes — so releases and history archaeology stay reliable. ## Core Features & Use Cases - Rebase-first landing: Fetch, rebase onto origin/main, and push with --force-with-lease instead of merging. - Stacked branch handling: Explains how to rebase dependent branches and open fresh PRs after GitHub closes them. - Commit discipline: Commit early and often with conventional prefixes (feat:, fix:, chore:) and --signoff so release automation cuts the right version. - Use Case: You finished a feature on a branch stacked on another PR. After the lower PR lands, rebase onto main, force-push, open a new PR referencing the old number, and merge with gh pr merge --rebase. ## Quick Start Ask the assistant to land your current branch following the repo's rebase-based Git workflow with conventional commit prefixes.

Frequently Asked Questions about getty-git-usage

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I land a branch with a linear Git history?▼

Fetch origin, rebase your branch onto origin/main instead of merging, then push with --force-with-lease. Merge the pull request using gh pr merge <n> --rebase --delete-branch to keep history linear.

Should I squash or rebase when merging a pull request?▼

Rebase, not squash. Squashing replaces individual feat:/fix: commit subjects with the PR title, and a title without a conventional prefix produces no release when the release workflow reads commit prefixes.

What happens to stacked PRs on GitHub when the base branch lands?▼

GitHub closes the dependent PR and refuses to reopen it. Rebase the next branch onto main, force-push, and open a fresh PR that references the old PR number so the discussion trail survives.

When is a merge commit acceptable instead of a rebase?▼

Merge commits are acceptable when a branch genuinely represents parallel work whose shape is worth preserving in history. They should not be used merely to avoid performing a rebase.

Why commit small changes separately instead of one big commit?▼

Small commits survive into main and make git bisect, single-commit reverts, and cherry-picks possible. Parking work until it is done lands as a lump that cannot be unpicked later.