git-fire

Qu'est-ce que git-fire ?

git-fire est un outil en ligne de commande pour la gestion du cycle de vie des dépôts sur plusieurs repositories Git. Son objectif principal est de vous permettre de créer des « points de contrôle » sur plusieurs repos avec un workflow unique et cohérent : il détecte les repositories, valide optionnellement les changements non validés, et pousse des branches/remotes de sauvegarde avec des garde-fous pour éviter la perte de travail local uniquement.

Le projet est conçu pour les situations où un déplacement fiable et traçable sur plusieurs repos est crucial — par exemple lorsque vous avez besoin d'un chemin de récupération cohérent et souhaitez éviter les boucles de push manuelles qui peuvent échouer (en raison de coupures réseau, problèmes d'authentification ou erreurs shell). Le projet est actuellement en bêta.

Fonctionnalités clés

• Point de contrôle multi-repo en une commande : détecte les repositories, puis exécute une séquence de push orientée sauvegarde au lieu d'exiger des étapes manuelles par repo.
• Validation automatique optionnelle des changements non validés : crée des commits à partir des modifications locales quand activé (le workflow par défaut valide automatiquement les changements non validés sauf si désactivé).
• Comportement de push de branches/remotes de sauvegarde : pousse des branches/remotes de sauvegarde dans le cadre du point de contrôle pour rendre le travail récupérable.
• Garde-fous et chemin de récupération traçable : conçu pour offrir un déplacement de récupération cohérent et inspectable sur plusieurs repositories.
• Mode aperçu dry-run : supporte une approche « aperçu d'abord (sûr) » via --dry-run pour observer ce que l'outil ferait.
• Mode script de bootstrap d'urgence en une ligne : un chemin « script de bootstrap d'urgence » est décrit pour les situations urgentes, avec recommandation d'inspecter d'abord scripts/emergency.sh.
• Comportements TUI et configuration : la documentation du repository inclut une TUI (avec captures d'écran et « profils de couleurs ») plus une section dédiée « Configuration et Comportements ».

Comment utiliser git-fire

1. Installez git-fire via l'une des méthodes documentées : Homebrew (macOS/Linuxbrew), WinGet (Windows), un script d'installation Linux, paquets natifs Linux (.deb/.rpm), ou installation Go.
2. (Recommandé) Aperçu des changements d'abord : exécutez git-fire --dry-run --path ~/projects pour examiner le comportement du point de contrôle sans effectuer les pushes de sauvegarde.
3. Exécutez le workflow de point de contrôle par défaut : lancez git-fire pour effectuer le point de contrôle multi-repo streamé standard décrit dans le README du repository.
4. Pour les situations urgentes, utilisez l'approche du script de bootstrap d'urgence uniquement après inspection de scripts/emergency.sh, et préférez les assets de release avec checksums quand possible.

Note : le projet indique que git-fire et git fire sont équivalents quand git-fire est dans votre PATH.

Cas d'usage

• Sauvegarde sur plusieurs repos avant un changement à haut risque : utilisez git-fire pour créer un point de contrôle sur plusieurs repositories en un workflow cohérent plutôt que des étapes de push répétitives par repo.
• Récupération d'un problème d'authentification/réseau avec une action planifiée unique : quand les boucles de push manuelles sont sujettes aux erreurs, utilisez le flux orienté sauvegarde de git-fire pour créer un point de contrôle traçable et récupérable sur les repos.
• Point de contrôle sur un sous-ensemble d'espace de travail : utilisez --path pour cibler un répertoire (exemple : --dry-run --path ~/projects) quand vous voulez limiter l'opération multi-repo.
• Bootstrap d'urgence quand une installation standard n'est pas possible : suivez l'approche « In case of fire » pour bootstrapper un chemin d'urgence, en utilisant RELEASE_TAG dans la commande comme indiqué dans la documentation.
• Équipes standardisant les étapes de cycle de vie des repositories : utilisez la promesse centrale documentée de git-fire et ses garde-fous pour maintenir des procédures de point de contrôle multi-repo cohérentes entre environnements.

FAQ

• git-fire est-il prêt pour la production ? Le projet indique explicitement qu'il s'agit d'un logiciel bêta. Il note que les flux de sauvegarde multi-repo de base sont utilisables aujourd'hui, tandis que certains éléments de roadmap ne sont pas encore implémentés (par exemple --backup-to et mode destination USB).

• Puis-je prévisualiser ce que git-fire va faire avant d'appliquer les changements ? Oui. Le README montre git-fire --dry-run --path ~/projects comme étape « aperçu d'abord (sûr) ».

• Comment fonctionne le bootstrap d'urgence ? Le README fournit une commande en une ligne qui télécharge et exécute scripts/emergency.sh depuis le repository à un RELEASE_TAG donné. Il conseille d'inspecter scripts/emergency.sh d'abord et mentionne que curl | bash exécute du code distant directement.

• Quelles méthodes d'installation sont disponibles ? Le README liste Homebrew, WinGet, un script d'installation Linux, paquets natifs Linux (.deb/.rpm), installation Go, et archives binaires depuis GitHub Releases.

• Que comprend « une commande » ? La promesse centrale documentée est de détecter les repos, valider automatiquement les changements non validés (sauf si désactivé), et pousser les sauvegardes pour éviter la perte de travail local uniquement.

Alternatives

• Flux de travail Git standard avec scripts par dépôt : vous pouvez écrire vos propres boucles shell autour de git status, git commit et git push, mais cela transfère à vous le fardeau de la cohérence et de la gestion des erreurs—précisément les modes de défaillance que git-fire vise à réduire.
• Outils Git multi-dépôts généralistes (utilitaires de gestion de dépôts) : ils peuvent aider à itérer sur de nombreux dépôts, mais git-fire est spécifiquement orienté vers la création de points de contrôle avec branches/distantes de sauvegarde et garde-fous décrits.
• Création manuelle de branches de sauvegarde par dépôt : c’est simple mais fastidieux et plus sujet aux erreurs sur de nombreux dépôts, surtout en cas de problèmes d’authentification ou réseau.
• Clients Git graphiques avec opérations par lots : certains clients proposent des actions groupées sur les dépôts, mais l’accent du README sur un bootstrap d’urgence, aperçu dry-run et flux de points de contrôle auditable cohérent peut différer des workflows centrés GUI.