Comment le gérer lorsqu'un commit en cours semble soudainement dépendre d'un autre qui n'est pas encore là?

Je n'ai pas d'expérience avec Git mais je fais de mon mieux pour m'y habituer, et jusqu'à présent je ne l'utilise que pour des projets sur lesquels je travaille seul.

Quand je code, il y a naturellement une approche descendante (car je ne peux pas connaître l'avenir), et il y a un thème récurrent:

Je fais du travail.
Je découvre que pour obtenir mon travail dans quelque chose de «commitable», je dois faire un autre travail.
L'autre travail mérite son propre engagement.

Par quelque chose d'engagement, je veux dire quelque chose qui se compile ou quelque chose qui n'est pas un gâchis total.
Et par quelque chose qui mérite son propre commit, je fais référence au fait que j'ai appris que les commits ne devraient faire qu'une seule chose.

La façon dont je le résous est lourde. Si l'autre travail se trouve dans un autre fichier, je crée une nouvelle branche, je m'y engage et je fusionne. Si le travail est dans le même fichier .. ugh .. Je fais une copie locale et réinitialise le fichier à son état dans HEAD, effectue la validation nécessaire et commence à restaurer mon travail à partir de la copie. Comment dois-je réellement gérer cela? Je n'imagine pas que c'est ainsi, n'est-ce pas? Je ne le suppose pas, car cela doit venir un peu souvent à tout le monde (qui ne connaît pas aussi l'avenir, au moins). Ou peut-être que mon flux de travail est susceptible d'être défectueux?

Il existe plusieurs façons de résoudre ce problème.

Si vous souhaitez effectuer les modifications pour le premier commit sans interférer avec vos modifications actuelles, vous voudrez peut-être utiliser git stash. Cela supprimera toutes vos modifications ouvertes, vous permettant de les restaurer plus tard. Utilisez git statuspour voir qu'ils ne sont plus présents. Créez maintenant le premier commit comme vous en avez l'habitude. Ensuite, vous pouvez utiliser git stash poppour restaurer vos modifications d'origine et créer le deuxième commit, en effectuant votre travail principal.

Une autre façon consiste à effectuer toutes les modifications requises, puis à créer deux validations, contenant toutes les deux une partie de votre travail. Pour ce faire, vous pouvez utiliser l'index (également appelé zone de transit) fourni par git. Il s'agit d'un domaine spécial que vous pouvez utiliser pour préparer des commits. En supposant que vous avez modifié plusieurs fichiers, vous pouvez ajouter chacun d'eux à l'index à l'aide de git add. Lors de cette opération, git commitseuls les fichiers ajoutés à l'index seront validés. git statusvous montrera quelles parties de vos modifications seront validées et lesquelles ne le seront pas. Par exemple, il ressemblera à cela après avoir changé les fichiers a.txt, b.txt et c.txt et après avoir fait git add a.txt:

On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        modified:   a.txt

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   b.txt
        modified:   c.txt

Lorsque vous faites git commitdans cet état, seules les modifications apportées à a.txt seront ajoutées à votre validation.

Vous pouvez également consulter les modifications exactes à valider à l'aide de git diff --cached, qui vous montrera un diff de toutes les modifications qui seront validées.

Si un fichier contient des modifications pour les deux validations, vous pouvez également n'en ajouter que des parties à l'index en utilisant "git add --patch b.txt". git vous fournira un mode interactif qui vous demandera chaque changement dans le fichier donné s'il doit être ajouté à l'index. Cela peut devenir plus difficile si vous avez des changements de lignes côte à côte, qui doivent être divisés dans les deux validations, mais il existe également des moyens de résoudre ce problème.

Si vous souhaitez en savoir plus sur la zone de transit, vous pouvez lire ceci: http://gitready.com/beginner/2009/01/18/the-staging-area.html

Vous pouvez également vouloir en savoir plus sur l'ajout interactif ici: http://nuclearsquid.com/writings/git-add/

Si vous utilisez une interface graphique pour Git, comme SourceTree par Atlassian, ou git gui, vous pouvez valider des parties de fichiers et laisser d'autres parties non validées. En fait, vous pouvez valider des lignes de code individuelles.

Je le fais fréquemment lorsque je tombe dans des trous de lapin comme vous le décrivez. C'est un excellent moyen de faire ce commit ou ce commit sensible en tant que précurseur du commit principal.

Vous pouvez le faire à partir de la ligne de commande, mais c'est un peu maladroit.

Lorsque vous pouvez valider au niveau du correctif Git et des lignes individuelles, vous n'avez pas besoin de créer de nouvelles branches, stash, commit, stash et merge. Continuez simplement à travailler et ne cassez pas le flux. Vous avez une bonne chose.