git-safety

par redis

Gardes de sécurité critiques pour les branches protégées : ne jamais commiter, pousser ou forcer la poussée directement vers les branches main, latest ou release ; aucun historique destructeur…

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

Plus de skills de redis

docs-sync
redis
Analyser l'implémentation et la configuration de la branche master pour trouver la documentation manquante, incorrecte ou obsolète dans docs/, README.md et les READMEs par package. Utiliser…
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
Examiner une URL de problème ou de demande de tirage GitHub en tant que mainteneur de node-redis, avec une évaluation progressive pour déterminer si la revendication est réelle, pratiquement importante, déjà…
official
pr-draft-summary
redis
Créez le bloc de résumé PR-ready requis, la suggestion de branche, le titre et la description de brouillon pour node-redis. Doit être utilisé avant la réponse finale chaque fois que le…
official
runtime-behavior-probe
redis
Planifier et exécuter des investigations sur le comportement d'exécution avec des scripts sonde TypeScript temporaires, des matrices de validation, des contrôles d'état et des rapports axés sur les résultats. Utiliser…
official
backend
redis
Modèles de développement backend NestJS pour l'API RedisInsight : structure des modules, services, contrôleurs, DTOs, injection de dépendances et gestion des erreurs. Utiliser lorsque…
official
branches
redis
Utiliser le kebab-case en minuscules avec le préfixe de type et l'identifiant du ticket. Les noms de branches doivent respecter les règles du workflow GitHub Actions (voir .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