agentleFS
sf-scalarsf-scalar/skiLL.Md/skills/dev-tools/git-workflow-branching/SKILL.md

git-workflow-branching

Skill6 starsChanged 6 months agoMITView on GitHub

When creating, updating, and merging code in a collaborative version control environment.

  • Deletes or force-pushes
  • Commits and pushes

The file

Show its rules and text

We split this skill into the rules it gives an agent

13 rules. About 0 are common, 10 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈10

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    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
  1. Distinctive:

    Sync Main: ALWAYS fetch and pull latest from main before creating branch

    line 49
  2. Very specific:

    Create Branch: Use convention type/ticket-id-short-description (e.g., feat/PROJ-123-add-login)

    line 50
  3. Distinctive:

    Commit Atomically: Commit in small logical chunks.

    line 51
  4. Distinctive:

    Delete Branch: Delete feature branch after merging (cleanup)

    line 56
  5. Distinctive:

    MUST NEVER push directly to main (always use PRs)

    line 59
  6. Very specific:

    MUST use Conventional Commits: feat:, fix:, docs:, chore:, refactor:, test:

    line 60
  7. Distinctive:

    MUST rebase before opening PR (no merge commits from main)

    line 61
  8. Distinctive:

    MUST delete feature branches after merging

    line 62
  9. Distinctive:

    MUST NOT commit with messages like "wip", "fixed typo", "trying again"

    line 63
  10. Distinctive:

    MUST resolve conflicts locally before pushing

    line 64
  11. Distinctive:

    MUST NOT force-push to shared branches

    line 65
  12. Distinctive:

    MUST keep feature branches <5 days old before merging

    line 66
  13. Very specific:

    NEVER commit secrets (use .gitignore, environment variables)

    line 102

≈ “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

Git Workflow & Branching

Purpose

Clean git history is essential for debugging (git bisect), code review, and team collaboration. This skill standardizes branch naming, commit formatting, and merging to maintain a readable, revertible, and bisect-able history.

When to use

  • Starting a new feature or bugfix ticket
  • Reviewing PRs and merging code into mainline
  • Hotfixing production environments
  • Onboarding new team members

When NOT to use

  • Dealing with complex merge conflicts (use git documentation)
  • Repository history rewrites (different concern)
  • CI/CD trigger configuration (separate skill)

Inputs required

  • Git repository with main branch
  • Remote repository (GitHub, GitLab, Gitea)
  • Team agreement on branch naming and commit conventions

Workflow

  1. Sync Main: ALWAYS fetch and pull latest from main before creating branch
  2. Create Branch: Use convention type/ticket-id-short-description (e.g., feat/PROJ-123-add-login)
  3. Commit Atomically: Commit in small logical chunks. MUST use Conventional Commits format
  4. Keep Branch Synced: Rebase against main frequently to avoid merge conflicts
  5. Push Regularly: Push to remote regularly (enables collaboration, backup)
  6. Rebase Before PR: Interactive rebase to clean up WIP commits before opening PR
  7. Squash Merge: Merge PR using squash-merge to keep main history clean
  8. Delete Branch: Delete feature branch after merging (cleanup)

Rules

  • MUST NEVER push directly to main (always use PRs)
  • MUST use Conventional Commits: feat:, fix:, docs:, chore:, refactor:, test:
  • MUST rebase before opening PR (no merge commits from main)
  • MUST delete feature branches after merging
  • MUST NOT commit with messages like "wip", "fixed typo", "trying again"
  • MUST resolve conflicts locally before pushing
  • MUST NOT force-push to shared branches
  • MUST keep feature branches <5 days old before merging

Anti-patterns

  • WIP Commits: Pushing commits like "wip", "fixed typo", "let me try again" to main
  • Long-lived Branches: Keeping branches active for weeks without syncing with main
  • Merge Commits: Allowing merge commits from main to pollute history (use rebase)
  • Squashing Too Early: Squashing before PR review (makes feedback hard to track)
  • Force Pushing to Shared: git push -f on branches other developers are using
  • Vague Messages: "Update stuff", "fix bug" (impossible to bisect later)

Failure conditions

  • Direct push to main detected
  • Merge conflicts exist when opening PR
  • Broken tests or CI failures on main
  • WIP commits in main history
  • Feature branches never deleted after merge

Validation checklist

  • Branch created from latest main
  • Branch name follows type/ticket-id-description format
  • All commits use Conventional Commits format
  • No "wip", "fixed typo", or vague commit messages
  • Commits are atomic (each solves one thing)
  • Rebase completed, no merge commits from main
  • All conflicts resolved locally
  • CI passes before PR merge
  • PR description links ticket
  • Branch deleted after merging

Output format

  • Branch naming: type/ticket-id-short-desc (e.g., feat/AUTH-42-oauth-integration)
  • Commit format: type(scope): description\n\nbody\n\nfooter
  • History: Linear commits on main (no merge commits)
  • Merge strategy: Squash-merge to single conventional commit

Security considerations

  • NEVER commit secrets (use .gitignore, environment variables)
  • Code review MUST happen before main (enforce via PR requirements)
  • Force-push MUST be disabled on main branch
  • Branch protection rules MUST require passing CI

Agent execution notes

  • Agent MAY: Create branches, make commits, rebase branches, resolve conflicts, open PRs
  • Agent MUST NEVER: Push directly to main, create WIP commits, force-push shared branches
  • Agent MUST ASK: Before force-pushing, before deleting branches, before modifying main history
  • Agent MUST VALIDATE: Branch follows naming convention, commits are conventional, CI passes

Example

❌ Anti-pattern (WIP commits, vague messages, no rebasing):

git checkout main
# Forgot to pull - out of sync
git checkout -b feature-branch
git commit -m "wip"
git commit -m "fixed typo"
git commit -m "let me try again"
git commit -m "update stuff"
git push origin feature-branch
# Merge directly to main without PR

✅ Correct pattern (Atomic commits, conventional, rebased, squashed):

git fetch origin
git checkout -b feat/PROJ-123-add-oauth

# Make atomic commits with conventional format
git commit -m "feat(auth): add oauth service initialization"
git commit -m "feat(auth): implement oauth callback handler"
git commit -m "test(auth): add oauth flow tests"

git push origin feat/PROJ-123-add-oauth

# Before PR: rebase and squash if needed
git fetch origin
git rebase origin/main

# Squash merge via PR (git will handle this)
# After merge:
git checkout main
git pull origin main
git branch -d feat/PROJ-123-add-oauth
git push origin --delete feat/PROJ-123-add-oauth

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.