Git add -p : mettre en scène des lignes spécifiques et effectuer des validations ciblées

Pour valider seulement une partie d'un fichier, effectuez les modifications souhaitées avec `git add -p -- path/to/file`, examinez-les avec `git diff --cached`, puis validez. Les modifications restantes restent dans vos fichiers de travail. Dans GitTree, ouvrez le fichier diff, sélectionnez les lignes modifiées et choisissez Stage Lines pour préparer le même type de commit ciblé.

Supposons que vous ayez corrigé un bug de validation de paiement, puis commencé à réorganiser le même composant. Un réviseur devrait être capable de comprendre la correction du bogue sans lire un refactor inachevé. Ce guide sépare ces changements avant qu’ils ne deviennent de l’histoire ancienne. L'exemple animé utilise GitTree, le client que nous créons pour macOS, Windows et Linux. La mise en scène partielle appartient au plan Free ; Les versions officielles actuelles nécessitent une connexion.

Arbre de travail, zone de préparation et commit : qu'est-ce qui est sauvegardé ?

La mise en scène est une étape de sélection, pas un commit ni une poussée. Un fichier peut être partiellement mis en scène : l'index contient une version tandis que votre éditeur affiche toutes les modifications. Si vous modifiez à nouveau après la préparation, la version intermédiaire n'est pas mise à jour silencieusement. Relisez-le à nouveau avant de vous engager. Le visual commit graph permet d'inspecter l'historique une fois que le commit existe.

Comment utiliser git add -p sur un fichier

Commencez par git status et inspectez tout ce qui a déjà été préparé. Le mode Patch ajoute les modifications sélectionnées à l'index existant ; il ne supprime pas les sélections antérieures. Dans cet exemple, remplacez src/checkout.ts par votre fichier texte suivi, puis acceptez uniquement le correctif de validation lorsque Git vous pose des questions sur chaque bloc.

git status
git diff --cached
git diff -- src/checkout.ts
git add -p -- src/checkout.ts
git diff --cached
git diff -- src/checkout.ts
git commit -m "fix: validate checkout input"

Exécutez la validation finale uniquement après avoir examiné la différence par étapes et testé le changement prévu. git diff --cached montre ce que le commit va enregistrer ; plain git diff montre ce qui restera non engagé. N'utilisez pas git commit -a et ne donnez pas de chemins de fichiers à git commit pour ce flux de travail : ces formulaires peuvent contourner la sélection partielle que vous venez de préparer.

Diviser un morceau lorsque le correctif et le refactor sont proches l'un de l'autre

Un morceau est un bloc de lignes modifiées à proximité avec contexte. Le mode Patch peut regrouper le correctif et le refactor. Utilisez s pour demander à Git de diviser le bloc. Si les modifications ne peuvent pas être séparées automatiquement, e ouvre un éditeur de correctifs ou un sélecteur de ligne visuel peut vous aider à choisir les ajouts et suppressions souhaités.

Pour un remplacement, considérez la ligne supprimée et son remplacement comme un seul changement logique. En sélectionner seulement la moitié peut produire du code que vous n’avez jamais vu dans votre éditeur. L'édition avancée des correctifs est facultative ; si vous ne pouvez pas expliquer le résultat mis en scène, annulez-le et choisissez une limite plus claire. Les commits ciblés doivent fonctionner de manière autonome et ne pas être simplement petits.

Télécharger GitTree pour examiner une différence mixte et créer visuellement des commits ciblés. Vous pouvez l'utiliser sur un référentiel existant à côté du terminal ; les deux lisent la même zone de transit Git.

Supprimez les modifications sans abandonner vos modifications

git restore --staged -- src/checkout.ts
# Or choose which staged blocks to remove:
git restore --staged -p -- src/checkout.ts

Ce sont des commandes alternatives. Avec --staged, la restauration modifie l'index plutôt que votre fichier de travail. Pour un référentiel avec des validations, il réinitialise normalement le contenu intermédiaire vers HEAD. Sans --staged, la restauration peut écraser les modifications de travail, alors gardez la distinction claire. Dans GitTree, choisissez Annuler la mise en scène, pas Supprimer, lorsque vous souhaitez uniquement modifier ce que comprend le prochain commit.

Pourquoi un fichier apparaît deux fois ou une ligne ne peut pas être transférée

Un fichier sous Fichiers préparés et Fichiers non préparés signifie généralement une préparation partielle ou une modification ultérieure, et non un fichier en double. Un nouveau fichier texte non suivi peut avoir besoin de git add -N -- path/to/new-file avant que le mode correctif puisse proposer son contenu. Les fichiers binaires ne contiennent pas de morceaux de texte ordinaires ; GitTree organise également les renommages, les pointeurs LFS et les modifications de sous-modules en tant qu'opérations sur l'ensemble du fichier. Si les espaces sont masqués, affichez-les avant de sélectionner les modifications contenant uniquement des espaces.

Si un éditeur ou un formateur modifie le fichier après avoir ouvert sa comparaison, GitTree peut refuser une sélection de ligne obsolète. Actualisez le diff et choisissez à nouveau. Évitez de diviser les modifications étroitement couplées juste pour atteindre un nombre de lignes plus petit. Pour une interruption de tâche, cachez le travail inachevé ; pour un historique mixte déjà validé, consultez le guide de rebase interactif.

Testez le commit que vous préparez, pas seulement les fichiers de l'éditeur

Votre commande de test normale s'exécute sur les fichiers de travail, qui incluent toujours des modifications non préparées. La réussite des tests là-bas ne prouve pas que la validation partielle est terminée. Pour une division importante, effectuez la première validation locale, puis inspectez et testez cet instantané validé dans une extraction propre ou un arbre de travail distinct. Ajoutez la dépendance manquante si elle échoue avant de partager la branche. Le guide worktree explique comment des dossiers séparés permettent de séparer ces versions.