Vous travaillez joyeusement sur quelque chose, et trouvez que les modifications dans ces fichiers sont prêtes. Vous ne voulez pas les voir lorsque vous lancez git diff, parce que vous allez travailler sur d’autres fichiers et les modifications à ces fichiers vous distrairaient de votre travail.

Quelqu’un vous demande de tirer, et les modifications paraissent valoir le coup d’être fusionnées.

Cependant, vous avez déjà sali l’index (c-à-d votre index ne correspond pas au commit HEAD). Mais vous savez que le tirage que vous allez faire n’affecte ni frotz.c ni filfre.c, donc vous rembobinez les modifications de l’index pour ces deux fichiers. Vos modifications dans l’arbre de travail restent là.

Puis vous pouvez tirer et fusionner, en laissant les modifications à frotz.c et filfre.c dans l’arbre de travail.

Cela sert le plus souvent quand vous vous êtes souvenu que ce que vous avez validé est incomplet, ou que vous avez mal orthographié votre message de validation, ou les deux. Cela laisse l’arbre de travail comme il était avant « reset ».

Corrige les fichiers de l’arbre de travail.

"reset" copie l’ancienne HEAD vers .git/ORIG_HEAD ; refait le commit en démarrant par son message de validation. Si vous n’avez pas besoin d’éditer plus le message, vous pouvez plutôt passer l’option -C.

Vous avez fait des commits, mais vous vous êtes aperçu qu’ils étaient prématurés pour la branche master. Vous voulez continuer à le polir dans une branche thématique, donc vous créez la branche theme/wip de la HEAD actuelle.

Rembobinez la branche master pour en éliminer ces trois commits.

Basculez sur la branche theme/wip et continuez à travailler.

Les trois derniers commits (HEAD, HEAD^ et HEAD~2) étaient mauvais et vous ne plus jamais les voir. Ne faites pas ceci si vous avez déjà fourni ces commits à quelqu’un d’autre. (Voir la section « RÉPARER UN REBASAGE AMONT » dans git-rebase[1] pour les implications d’une telle action.)

L’essai de mettre à jour depuis l’amont a apporté beaucoup de conflits ; vous n’êtes pas prêt à passer beaucoup de temps à les fusionner maintenant, donc vous décidez de le faire plus tard.

"pull" n’a pas créé de commit de fusion, donc git reset --hard qui est synonyme de git reset --hard HEAD nettoie le bazar dans l’index et l’arbre de travail.

Fusionne une branche thématique dans la branche actuelle, qui a résulté en une avance rapide.

Mais vous avez décidé que la branche thématique n’est pas encore prête pour la publication. "pull" et "merge" laissent toujours le sommet originel de la branche actuelle dans ORIG_HEAD, donc la réinitialisation dure sur elle remet votre fichier d’index et l’arbre de travail à cet état et réinitialise le sommet de la branche à ce commit.

Même si vous pouviez avoir des modifications locales dans votre arbre de travail, vous pouvez lancer git pull en toute sécurité quand vous savez que les modifications dans l’autre branche n’entrent pas en conflit avec elles.

Après inspection du résultat de la fusion, vous pouvez trouver que cette modification dans l’autre branche n’est pas satisfaisante. Lancer git reset --hard ORIG_HEAD vous ramènera à l’état antérieur, mais cela éliminera aussi vos modifications locales, ce que vous ne désirez pas. git reset --merge conserve vos modifications locales.

Ce commit sera écrasé donc un message de validation jetable, c’est OK.

Ceci élimine le commit « instantané » de l’historique des commits et met votre arbre de travail dans l’état précédent cet instantané.

À ce point, le fichier d’index a toujours toutes les modifications en cours que vous avez validées comme « instantané en cours ». Ceci met à jour l’index pour afficher vos fichiers en cours d’édition comme non validés.

Ceci supprime un fichier de l’index tout en le conservant dans le répertoire de travail.

Ceci valide tous les autres fichiers dans l’index.

Ajouter à nouveau le fichier à l’index.

Ceci valide vos premières éditions dans branche1.

Dans un monde idéal, vous pourriez avoir réalisé que le commit précédent n’appartenait pas au nouveau sujet quand vous avez créé et avez basculé sur branche2 (c-à-d git switch -c branche2 debut), mais personne n’est parfait.

Mais vous pouvez utiliser reset --keep pour retirer le commit non voulu après avoir basculé sur branche2.

Réinitialise d’abord l’historique en arrière d’un commit de manière à retirer le commit original, mais laisse l’arbre de travail avec toutes ses modifications. Le drapeau -N garantit que tous les nouveaux fichiers ajoutés avec HEAD sont toujours marqués de telle manière que git add -p les trouve.

Ensuite, on sélectionne interactivement les sections de diff à ajouter en utilisant git add -p. Ceci vous demandera pour chaque section de diff l’une après l’autre et vous pouvez répondre simplement « oui, à inclure », « non, ne pas inclure » ou même utiliser la fonctionnalité puissante d’édition de la section.

Une fois satisfait des sections à inclure, vous devriez vérifier ce qui a été préparé pour la première validation en utilisant git diff --cached. Cela montre toutes les modifications qui ont été indexées et sont sur le point d’être validées.

Ensuite, valider les modifications stockées dans l’index. L’option -c indique de pré-remplir le message de validation avec le message original qui a servi au premier commit. C’est utile pour éviter de le retaper. Le HEAD@{1} est une notation spéciale pour le commit que HEAD a été avant le commit original réinitialisé (il y a une modification). Voir git-reflog[1] pour plus de détails. Vous pouvez aussi utiliser une référence à tout autre commit valide.

Vous pouvez répéter les étapes 2 à 4 plusieurs fois pour scinder le code original en un certain nombre de commits.

Maintenant, vous avez séparé beaucoup des modifications dans leurs propres commits, et pourriez ne plus utiliser le mode patch du git add pour sélectionner toutes les modifications non validées restantes.

Une fois de plus, vérifiez que vous avez inclus ce que vous souhaitez. Vous souhaitez peut-être vérifier que git diff ne montre aucune modification restante à valider plus tard.

Et finalement crée le commit final.