Commiter une partie d’un fichier
Ces blocs sont des cas différents, pas un script unique. Choisissez celui de votre dépôt. Remplacez branches, chemins et VERIFIED_COMMIT avant usage. Les commandes d’annulation concernent seulement leur opération active ; n’exécutez pas les deux alternatives.
Réponse courte
Git crée le commit à partir de l’index. Indexez seulement la correction et laissez les autres modifications dans le répertoire de travail pour des commits séparés.
Exemple et conditions
L’exemple contient une correction et un affichage de débogage dans le même fichier. Ces deux modifications de texte doivent être examinables séparément.
Examiner avant de modifier
Comparez git diff et git diff --cached. Le premier montre les modifications non indexées ; le second montre exactement le contenu du prochain commit.
git status --short
git diff
git diff --cachedGarder une référence ou un checkout séparé
Indexer un changement n’efface pas la modification restante. L’index et le répertoire de travail restent deux états que vous pouvez examiner séparément.
Premier parcours
Dans FluxGit, ouvrez le diff et utilisez Stage change sur la correction. Vérifiez le panneau de commit : l’affichage de débogage doit rester non indexé.
Choisir l’autre résultat consciemment
Au terminal, git add -p permet d’accepter ou de refuser les hunks. Les options s et e peuvent séparer un hunk ou modifier son patch selon le cas.
git add -p -- app.py
git diff --cachedLimites et exceptions
La plus petite unité dans FluxGit est un changement à l’intérieur d’un hunk. Un changement de six lignes est indexé entier, pas une sélection arbitraire dessinée à la souris.
Conflits et nettoyage
Désindexer conserve le fichier ; abandonner un changement modifie son contenu. FluxGit crée une capture de sécurité avant l’abandon partiel : ce sont des actions distinctes.
Vérifier le résultat
Lisez git diff --cached avant le commit et git show ensuite. Vérifiez aussi git diff pour confirmer que le travail restant est toujours dans le fichier.
git show --stat HEAD
git diff
git status --shortQuestions fréquentes
Pour un commit ordinaire privé, git reset --soft HEAD^ peut replacer le contenu dans l’index. Vérifiez l’état et coordonnez toute réécriture d’un historique partagé.
Examiner l’opération dans FluxGit
Commit Studio garde le diff et le message ensemble. Examinez le contenu pendant la rédaction et construisez des commits à intention claire.
Références officielles Git
Faire un commit d’une partie d’un fichier avec Git
Vous avez corrigé un bug et laissé un print de débogage dans le même fichier ? Préparez seulement la correction. Découvrez la zone de préparation Git, Stage change dans FluxGit et git add -p.
Regarder sur YouTube — ouvre un nouvel onglet
Enregistré dans un dépôt de test.
Lire la transcription de la narration
- Vous avez corrigé un bug et laissé un print de débogage dans le même fichier. Vous voulez un commit propre : la correction, sans le print.
- Voici le fichier dans FluxGit : app.py, avec deux modifications.
- Voici pourquoi cela fonctionne. Git ne commite pas votre dossier, mais la zone de préparation. Les deux modifications sont d’abord uniquement sur disque. Stage change place seulement la correction dans la zone de préparation. Le commit prend exactement cela, et le print reste sur disque, non commité.
- Ouvrez le fichier. Le diff montre les deux modifications, chacune avec son bouton Stage change.
- Cliquez sur Stage change pour la correction. Seule cette modification est préparée ; le print reste où il est.
- De retour dans le panneau de commit : la correction est préparée, le print ne l’est pas.
- Écrivez le message, puis faites le commit.
- Le nouveau commit contient la correction, et seulement elle. Le print reste sur disque, non commité.
- Vous changez d’avis ? Annuler retire le commit. La correction revient dans la zone de préparation, sans modifier vos fichiers.
- Dans le terminal, l’équivalent est git add -p. Git vous interroge sur chaque modification : oui pour la correction, non pour le print, puis faites le commit.
- Récapitulatif : préparez des modifications, pas des fichiers entiers. Une idée par commit. Annulez en cas d’erreur. Prochaine leçon : corriger le dernier commit.