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.