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
In this repository13 other files it gives its agents.
- caching-strategiesSkill
- event-driven-designSkill
- logging-observability-standardsSkill
- api-design-restSkill
- database-query-optimizationSkill
- error-handling-architectureSkill
- code-review-guidelinesSkill
- ci-cd-pipeline-architectureSkill
- debugging-strategiesSkill
- dom-security-hardeningSkill
- react-component-designSkill
- state-management-patternsSkill
- accessibility-ui-designSkill
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
- Distinctive: line 49
Sync Main: ALWAYS fetch and pull latest from main before creating branch
- Very specific: line 50
Create Branch: Use convention type/ticket-id-short-description (e.g., feat/PROJ-123-add-login)
- Distinctive: line 51
Commit Atomically: Commit in small logical chunks.
- Distinctive: line 56
Delete Branch: Delete feature branch after merging (cleanup)
- Distinctive: line 59
MUST NEVER push directly to main (always use PRs)
- Very specific: line 60
MUST use Conventional Commits: feat:, fix:, docs:, chore:, refactor:, test:
- Distinctive: line 61
MUST rebase before opening PR (no merge commits from main)
- Distinctive: line 62
MUST delete feature branches after merging
- Distinctive: line 63
MUST NOT commit with messages like "wip", "fixed typo", "trying again"
- Distinctive: line 64
MUST resolve conflicts locally before pushing
- Distinctive: line 65
MUST NOT force-push to shared branches
- Distinctive: line 66
MUST keep feature branches <5 days old before merging
- Very specific: line 102
NEVER commit secrets (use .gitignore, environment variables)
≈ “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.
Files
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
mainbranch - Remote repository (GitHub, GitLab, Gitea)
- Team agreement on branch naming and commit conventions
Workflow
- Sync Main: ALWAYS fetch and pull latest from
mainbefore creating branch - Create Branch: Use convention
type/ticket-id-short-description(e.g.,feat/PROJ-123-add-login) - Commit Atomically: Commit in small logical chunks. MUST use Conventional Commits format
- Keep Branch Synced: Rebase against
mainfrequently to avoid merge conflicts - Push Regularly: Push to remote regularly (enables collaboration, backup)
- Rebase Before PR: Interactive rebase to clean up WIP commits before opening PR
- Squash Merge: Merge PR using squash-merge to keep main history clean
- 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 -fon branches other developers are using - Vague Messages: "Update stuff", "fix bug" (impossible to bisect later)
Failure conditions
- Direct push to
maindetected - 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-descriptionformat - 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-oauthDoes 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
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.

