e-reitbauere-reitbauer/habits/skills/branching/SKILL.md

branching

Skill1 starsChanged 6 days agoMITView on GitHub

Use when creating, naming, syncing, merging or cleaning up git branches, when deciding whether work goes on a branch or straight to main, when choosing merge vs rebase vs squash, or when asked which branching strategy a project should use (trunk-based, GitHub Flow, Git Flow, release branches).

Deletes or force-pushes
Commits and pushes

3 other projects use a version of this.

Adopted by

Most recently taken up by

nguyenthanhtat/screen1-claudetheir own version, first seen Nov 1, 2026
andr-ca/agentharnesstheir own version, first seen Oct 15, 2026
lintangknitto/agent-skillstheir own version, first seen Sep 23, 2026

Other versions3 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 3
nguyenthanhtat/screen1-claude★ 2same name
andr-ca/agentharness★ 1same name
lintangknitto/agent-skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository15 other files it gives its agents.
- cinematicSkill
- commitSkill
- contextSkill
- dependenciesSkill
- errorsSkill
- hygieneSkill
- new-unitSkill
- patternsSkill
- prSkill
- researchSkill
- secretsSkill
- shipSkill
- uiSkill
- unitsSkill
- versioningSkill

The file

We split this skill into the rules it gives an agent

5 rules. About 0 are common, 4 are distinctive, and 1 is very specific to this project.

≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
1
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

Distinctive:
Follow the project's strategy.
line 13
Distinctive:
When asked to set one up, recommend GitHub Flow unless the release cadence or support needs call for another, and say why.
line 30
Distinctive:
Keep branches short-lived and focused on one change.
line 36
Very specific:
Never force-push a shared branch.
line 38
Distinctive:
After the merge, delete the branch locally and on the remote, and switch back to the base.
line 40

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “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

Branching

1. Detect the strategy in use

Follow the project's strategy; don't introduce a new one as a side effect.

Branches: git branch -a. A long-lived develop (plus release/*, hotfix/*) means Git Flow; release/x.y branches mean release branches; only main plus short feature branches means GitHub Flow or trunk-based.
How changes land: gh pr list --state merged --limit 10 --json baseRefName,headRefName,mergeCommit and git log --merges --oneline -10. PR merges into main mean a branch-and-PR flow; direct commits on main mean trunk-based or a solo project.
Merge style: merge commits, squash (one commit per PR on main) or rebase (linear history). Check the repo settings (gh repo view --json squashMergeAllowed,mergeCommitAllowed,rebaseMergeAllowed) and match it.
Protection: if main is protected or every change arrives by PR, never commit to it directly.
Branch names: look at recent ones and copy the pattern (feat/140-live-player-map, fix/login-redirect, user/topic).

2. The strategies, and when each fits

Strategy	Shape	Fits
Trunk-based	everyone integrates into `main` daily; branches live hours, not days; features hidden behind flags	strong CI, continuous deployment, small experienced teams
GitHub Flow	short-lived feature branch, PR, review, merge to `main`, deploy from `main`	most teams and web projects; the default to recommend
Git Flow	`develop` for integration, `release/` to stabilize, `hotfix/` from `main`, `main` = released	scheduled releases of versioned software that maintains past versions
Release branches	`main` moves on; `release/x.y` branches get only backported fixes	supporting several released versions at once (libraries, mobile apps in review)

When asked to set one up, recommend GitHub Flow unless the release cadence or support needs call for another, and say why.

3. Working on branches

Name it type/scope: feat/<issue>-<short-topic>, fix/<topic>, chore/<topic>, lowercase with hyphens, matching the commit types. Put the issue number in when there is one.
Branch from the up-to-date base (git fetch first): main, or develop under Git Flow, or the release branch for a backport.
Keep branches short-lived and focused on one change. Split unrelated work into its own branch.
Stay current with the base: rebase a private branch onto it, or merge the base in once the branch is shared. Never rewrite history others have pulled.
Never force-push a shared branch. On your own branch after a rebase, use git push --force-with-lease, never plain --force.
Resolve conflicts by understanding both sides; never take "ours" or "theirs" wholesale without reading.
After the merge, delete the branch locally and on the remote, and switch back to the base.

4. Before opening the PR

The branch builds and passes tests, the diff contains only this change, and it is pushed with an upstream (git push -u origin <branch>). Then open the PR with the pr skill.

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.

Check your setup, free