git-safety

작성자: redis

보호된 브랜치에 대한 중요 안전 가드레일: main, latest 또는 release 브랜치에 직접 커밋, 푸시 또는 강제 푸시하지 말 것; 파괴적인 기록 작업 금지…

npx skills add https://github.com/redis/redisinsight --skill git-safety

Git Safety Rules for AI Agents

🚫 CRITICAL: Protected Branch Rules

AI agents must NEVER commit to or push to protected branches under any circumstances.

Protected Branches

  • main - Primary production branch
  • latest - Latest stable release
  • release/* - Release branches (e.g., release/v2.0.0)

This is a non-negotiable rule that applies to all scenarios:

Prohibited Actions

  • Direct commits - Never run git commit while on a protected branch
  • Direct pushes - Never run git push origin <protected-branch> or git push while on a protected branch
  • Force pushes - Never run git push --force or git push -f targeting protected branches
  • Merging into protected branches locally - Never run git merge <branch> while on a protected branch
  • Rebasing protected branches - Never run git rebase while on a protected branch
  • Resetting protected branches - Never run git reset while on a protected branch

Required Workflow

  1. Always create a feature branch before making any changes
  2. Verify current branch before any git operation using git branch --show-current
  3. Create Pull Requests for all changes - let the review process handle merging

Pre-Push Checklist

Before executing any push command, AI agents must:

  1. ✅ Confirm current branch is NOT a protected branch (main, latest, release/*)
  2. ✅ Verify the remote and branch target

Error Recovery

If accidentally on a protected branch with uncommitted changes:

  1. Stash changes: git stash
  2. Create new branch: git checkout -b <appropriate-branch-name>
  3. Apply changes: git stash pop
  4. Continue work on the new branch

Rationale

  • Protected branches represent production-ready or release code
  • All changes must go through code review via Pull Requests
  • Direct pushes bypass CI/CD checks and team review
  • Mistakes on protected branches can affect the entire team and deployment pipeline

redis의 다른 스킬

docs-sync
redis
마스터 브랜치의 구현 및 구성을 분석하여 docs/, README.md, 패키지별 README에서 누락되거나, 부정확하거나, 오래된 문서를 찾습니다.
official
implement-command
redis
Add a new Redis command (or command variant) to node-redis end-to-end — the `<NAME>.ts` Command file, its registration with JSDoc in the package…
official
maintainer-review
redis
GitHub 이슈 또는 풀 리퀘스트 URL을 node-redis 관리자로서 검토하고, 해당 주장이 실제인지, 실질적으로 중요한지, 이미 처리되었는지에 대한 단계적 평가를 수행합니다.
official
pr-draft-summary
redis
node-redis에 필요한 PR 준비 요약 블록, 브랜치 제안, 제목 및 초안 설명을 생성합니다. 최종 응답 전에 항상 사용해야 합니다...
official
runtime-behavior-probe
redis
임시 TypeScript 프로브 스크립트, 검증 매트릭스, 상태 제어, 결과 우선 보고서를 사용하여 runtime-behavior-probe 조사를 계획하고 실행합니다. 사용…
official
backend
redis
NestJS 백엔드 개발 패턴: RedisInsight API를 위한 모듈 구조, 서비스, 컨트롤러, DTO, 의존성 주입 및 오류 처리. 다음 경우에 사용…
official
branches
redis
소문자 케밥 케이스에 유형 접두사와 이슈/티켓 식별자를 사용하세요. 브랜치 이름은 GitHub Actions 워크플로우 규칙(.github/workflows/enforce-branch-name-rules.yml 참조)과 일치해야 합니다.
official
code-quality
redis
Code-quality standards for RedisInsight: TypeScript strictness, naming conventions (camelCase, PascalCase, UPPER_SNAKE_CASE), linting rules, no `any` without…
official