Git

Le rôle de Git dans un projet OrbitWake

Dans un projet versionné, Git permet de comprendre ce qui a changé, où vous travaillez et quelles différences existent entre l’état actuel et l’historique du dépôt.

Ces informations peuvent être utiles pour expliquer un bug, préparer une revue, comprendre un refactor ou vérifier qu’une modification reste limitée à la portée attendue.

OrbitWake ne doit toutefois pas confondre contexte Git et permission Git : lire l’état d’un dépôt n’autorise pas automatiquement la création d’un commit, le changement de branche, le push ou toute opération qui modifie l’historique.

Vérifier l’état du dépôt

Avant une tâche qui peut modifier du code, git status permet de voir les fichiers modifiés, ajoutés ou non suivis. C’est une commande Git standard, indépendante d’OrbitWake.

$ git status

Cette vérification est particulièrement utile avant une tâche multi-fichiers. Elle permet de distinguer les changements déjà présents de ceux qui seront éventuellement produits ensuite.

Voir les changements locaux

git diff affiche les différences non indexées par rapport à l’état suivi par Git. Utilisez-le pour inspecter ce qui a changé avant d’accepter ou de poursuivre une modification.

$ git diff

Pour un workflow prudent, lisez le diff avant les opérations qui auront des effets durables comme un commit ou un push.

Connaître la branche courante

La branche courante fait partie du contexte de travail. Elle vous indique où vos changements locaux seront associés si vous les validez ensuite avec Git.

$ git branch --show-current

Vérifier la branche est particulièrement important avant une modification importante, une opération de publication ou une tâche qui doit rester isolée du flux principal.

Lire l’historique récent

L’historique peut fournir un contexte utile sur les changements récents sans modifier le dépôt. Une vue compacte permet de voir les derniers commits rapidement.

$ git log --oneline -n 10

Cette commande peut aider à comprendre le rythme des modifications et à repérer un changement récent lié à un problème, mais elle ne remplace pas l’analyse des fichiers concernés.

Lecture Git et opérations d’écriture

Les commandes git status, git diff, git branch --show-current et git log servent ici d’exemples de lecture. Elles aident à comprendre le dépôt sans créer de commit ni pousser de changement.

À l’inverse, des opérations comme créer un commit, changer de branche, effectuer un merge, rebase, reset, push ou modifier un remote peuvent altérer l’état local ou distant. Elles nécessitent davantage de contrôle.

Workflow Git recommandé avant une modification

Pour une tâche sensible ou multi-fichiers, commencez par établir l’état du projet avant de demander des modifications.

$ git status
$ git branch --show-current
$ git diff
$ orbitwake

Les trois premières lignes sont des commandes Git standard. La dernière démarre OrbitWake dans le projet courant. Ce workflow permet de savoir où vous êtes et quels changements existent déjà avant toute nouvelle intervention.

Opérations Git sensibles

Les opérations qui modifient l’historique ou publient des changements doivent être traitées avec davantage de prudence. Parmi elles : commit, amend, merge, rebase, reset, push, force-push et modifications de remote.

Le niveau exact de permission qu’OrbitWake demandera avant ces opérations sera documenté dans Permissions shell et dans les futurs workflows Git du produit.

La documentation publique ne prétend pas qu’une commande OrbitWake existe pour effectuer ces actions tant que l’interface correspondante n’est pas confirmée.

Bonnes pratiques

Vérifiez toujours la branche et les changements locaux avant une opération importante. Gardez les modifications concentrées sur une tâche afin que les diffs restent lisibles et vérifiables.

Évitez de mélanger dans le même changement des corrections sans rapport. Pour une tâche importante, inspectez le diff avant de committer et assurez-vous que les fichiers sensibles, générés ou temporaires ne sont pas inclus par erreur.

Lorsque le dépôt contient déjà des changements locaux qui ne viennent pas de la tâche courante, traitez-les comme un contexte à préserver plutôt que comme quelque chose à écraser ou à réinitialiser automatiquement.

Ce qui reste à documenter

Les commandes Git directement orchestrées par OrbitWake, la création de branches, les commits assistés, les messages de commit, le push, la gestion des remotes, les conflits, les worktrees et les politiques de confirmation ne sont pas encore publiés comme contrat stable du CLI.

Ces capacités seront documentées séparément lorsqu’elles seront confirmées. Les exemples présents ici utilisent uniquement des commandes Git standard de lecture et le lancement confirmé d’OrbitWake.

Étapes suivantes

Continuez avec Permissions shell pour comprendre comment OrbitWake doit traiter les commandes locales, les opérations sensibles et les confirmations avant exécution.