Quelle est l'utilité de la zone de transit dans Git?

Question

Quel est l'intérêt de git add . ou git add <filename> pour l'ajouter à la zone de transit? Pourquoi pas simplement git commit -m "blabla"?

Je ne comprends pas la valeur de la zone de rassemblement.

Answer 1

Il existe de nombreuses utilisations de la mise en scène dans git. Certains sont énumérés ci-dessous: -

1. la mise en scène vous aide à diviser une grande modification en plusieurs validations - Disons que vous avez travaillé sur une modification de grande envergure, impliquant beaucoup de fichiers et pas mal de sous-tâches différentes. Vous n'avez en fait commis aucun de ces actes - vous étiez "dans la zone", comme on dit, et vous ne vouliez pas penser à diviser les commits de la bonne façon à ce moment-là. (Et vous êtes assez intelligent pour ne pas tout faire sur le klaxon de gros commit!). Maintenant que la modification est testée et fonctionne, vous devez valider tout cela correctement, en plusieurs validations propres chacune concentrée sur un aspect des modifications de code. Avec l'index, il suffit de mettre en scène chaque ensemble de modifications et de valider jusqu'à ce qu'aucune autre modification ne soit en attente. Fonctionne vraiment bien avec git gui si vous y êtes aussi, ou vous pouvez utiliser git add -p ou, avec les gits plus récents, git add -e.

2. la mise en scène aide à réviser les modifications - La mise en scène vous aide à "cocher" les modifications individuelles lorsque vous passez en revue un commit complexe et à vous concentrer sur les éléments qui n'ont pas encore passé votre examen. Laisse-moi expliquer. Avant de vous engager, vous examinerez probablement toute la modification en utilisant git diff. Si vous mettez en scène chaque changement au fur et à mesure que vous l'examinez, vous constaterez que vous pouvez mieux vous concentrer sur les changements qui ne sont pas encore échelonnés. git gui est génial ici. Ses deux volets de gauche affichent respectivement les modifications non mises en scène et les mises en scène, et vous pouvez déplacer des fichiers entre ces deux volets (étape/décompression) simplement en cliquant sur l'icône à gauche du nom de fichier. Encore mieux, vous pouvez même effectuer des modifications partielles dans un fichier. Dans le volet droit de git gui, faites un clic droit sur une modification que vous approuvez et choisissez "stage hunk". Juste ce changement (pas le fichier entier) est maintenant mis en scène; en fait, s'il y a d'autres changements, non progressifs, dans ce même fichier, vous constaterez que le fichier apparaît maintenant dans les volets supérieur et inférieur gauche!

3. la mise en scène est utile lorsqu'une fusion a des conflits - Lorsqu'une fusion se produit, les modifications qui fusionnent proprement sont mises à jour à la fois dans la zone de mise en attente et dans votre arbre de travail. Seules les modifications qui n'ont pas fusionné correctement (c'est-à-dire qui ont provoqué un conflit) s'affichent lorsque vous effectuez un diff git, ou dans le volet supérieur gauche de git gui. Encore une fois, cela vous permet de vous concentrer sur les éléments qui nécessitent votre attention - les conflits de fusion.

4. la mise en scène vous aide à conserver les fichiers locaux supplémentaires - Habituellement, les fichiers qui ne doivent pas être validés vont dans .gitignore ou dans la variante locale, .git/info/exclude. Cependant, vous souhaitez parfois une modification locale d'un fichier qui ne peut pas être exclu (ce qui n'est pas une bonne pratique mais peut parfois se produire). Par exemple, vous avez peut-être mis à niveau votre environnement de génération et cela nécessite maintenant un indicateur ou une option supplémentaire pour la compatibilité, mais si vous validez la modification dans le Makefile, les autres développeurs auront un problème. Bien sûr, vous devez discuter avec votre équipe et trouver une solution plus permanente, mais pour le moment, vous avez besoin de ce changement dans votre arbre de travail pour effectuer n'importe quel travail! Une autre situation peut être que vous voulez un nouveau fichier local temporaire et que vous ne voulez pas vous soucier du mécanisme d'ignorance. Cela peut être des données de test, un fichier journal ou un fichier de trace, ou un script Shell temporaire pour automatiser certains tests ... peu importe. Dans git, tout ce que vous avez à faire est de ne jamais mettre en scène ce fichier ou ce changement. C'est tout.

5. la mise en scène vous aide à vous faufiler dans de petits changements - Disons que vous êtes au milieu d'un changement quelque peu important et que l'on vous parle d'un bogue très important qui doit être corrigé dès que possible. La recommandation habituelle est de le faire sur une branche distincte, mais disons que ce correctif n'est en fait qu'une ligne ou deux, et peut être testé tout aussi facilement sans affecter votre travail actuel. Avec git, vous pouvez rapidement effectuer et valider uniquement ce changement, sans valider toutes les autres choses sur lesquelles vous travaillez toujours. Encore une fois, si vous utilisez git gui, tout ce qui se trouve dans le volet inférieur gauche est validé, alors assurez-vous que seule la modification est là et validez, puis appuyez sur!

Answer 2

Il vaut la peine de comparer la façon dont Git gère cela - Git vous informe et utilise la zone de transit - avec la façon dont Mercurial gère cela. Dans Mercurial, vous travaillez exactement comme vous le suggérez: vous exécutez simplement hg commit et Mercurial comprennent ce que vous avez changé et le commettent. Vous devez hg add un nouveau fichier , mais si vous ne faites que modifier des fichiers existants, il n'y a rien de spécial à faire: vous les changez, vous les validez et vous êtes terminé.

Le comportement de Mercurial semble (et à mon avis, a été) beaucoup plus convivial. Git vous permet en fait d'obtenir le même effet en utilisant git commit -a. Autrement dit, vous ajoutez simplement -a à toutes les autres options que vous utiliserez, et Git fera à peu près la même chose que Mercurial. Mais c'est une sorte de béquille, car finalement, vous trouverez quelque chose que Git a fait qui est tout à fait inexplicable à moins que vous ne connaissiez la zone de transit.

réponse de Hidd3N montre un certain nombre de façons d'utiliser la zone de transit de Git. Mais si vous reculez un peu et comparez Mercurial et Git, vous pouvez, je pense, voir beaucoup plus de ce qui se passe vraiment.

N'oubliez pas que le travail de tout système de contrôle de version (VCS) est de vous permettre de récupérer chaque version validée jamais . (Et, comme Git et Mercurial fonctionnent tous les deux sur la base de l'ensemble du système , ils sont faciles à comparer ici. Il existe des VCS beaucoup plus anciens qui fonctionnent sur un fichier à la fois: vous devez spécifiquement archiver/valider chaque fichier individuel. Git et Mercurial font un instantané de tout-en-un.) Ces instantanés validés devraient durer éternellement et ne jamais changer du tout. Autrement dit, ils sont en lecture seule .

Cependant, les fichiers en lecture seule ne conviennent pas. Ainsi, tout VCS doit avoir, en quelque sorte/quelque part, deux choses distinctes:

• l'endroit où vous travaillez sur des fichiers: c'est votre arbre de travail ; et
• l'endroit où les instantanés sont stockés: c'est votre base de données de version, ou référentiel, ou un autre Word — Git appelle ces choses objets tandis que Mercurial a un plus compliqué ensemble de structures, appelons-les simplement objets ici.

La zone de stockage d'objets de Git a un tas d'objets en lecture seule: en fait, un pour chaque fichier, chaque commit, etc. Vous pouvez ajouter de nouveaux objets à tout moment, mais vous ne pouvez modifier aucun objet existant.

Comme le démontre Mercurial, il n'y a pas d'exigence pour une zone de transfert séparée: le VCS peut utiliser l'arborescence comme commit proposé. Lorsque vous exécutez hg commit, Mercurial compile l'arbre de travail et en fait un commit. Lorsque vous apportez des modifications dans l'arborescence de travail, vous modifiez la prochaine validation proposée. Le hg status commande vous montre ce que vous proposez de valider, ce qui est: tout ce qui est différent entre la validation actuelle et l'arbre de travail.

Git, cependant, choisit d'interposer cette zone intermédiaire, à mi-chemin entre les validations en lecture seule et l'arbre de travail en lecture/écriture. Cette zone intermédiaire, la zone de transit ou l'index ou cache , contient le prochain commit proposé.

Vous commencez par vérifier certains commit. À ce stade, vous avez trois copies de chaque fichier:

• L'un se trouve dans le commit actuel (que Git peut toujours trouver par le nom HEAD). Celui-ci est en lecture seule; vous ne pouvez pas le changer. C'est sous une forme spéciale, compressée (parfois très compressée), Git uniquement.
• L'un se trouve dans l'index/zone de transit. Celui-ci correspond à HEAD maintenant, mais il peut être modifié. C'est celui proposé pour entrer dans le prochain commit. Ceci est également sous la forme spéciale Git uniquement.
• Le dernier est dans votre arbre de travail, sous une forme ordinaire où vous pouvez travailler dessus.

Quelle git add fait est de copier des fichiers de votre arbre de travail, dans la zone de transit, écrasant celui qui correspondait à HEAD commettre.

Lorsque vous exécutez git status, il doit faire deux comparaisons distinctes. On compare le HEAD commit à l'index/staging-area, pour voir ce qui se passe être différent dans le prochain commit. Voici ce qui est to be committed. La deuxième comparaison trouve ce qui est différent entre l'index/zone de transfert et l'arbre de travail. Voici ce qui est not staged for commit.

Lorsque vous exécutez git commit -a, Git effectue simplement la zone de copie vers la zone de transfert en fonction de la deuxième comparaison. Plus précisément, il exécute l'équivalent de git add -u. (Il le fait secrètement avec une zone de transit temporaire , au cas où la validation échouerait pour une raison quelconque, de sorte que votre zone/index de transfert normal ne soit pas perturbé pendant la durée de la validation. Cela dépend en partie de git commit arguments également. Normalement, cela a tendance à être invisible, au moins jusqu'à ce que vous commenciez à écrire des hooks de validation complexes.)

Answer 3

Si vous pensez que la mise en scène est inutile, vous pouvez également être conscient de la pleine puissance du développement git et du logiciel. La mise en scène signifie que vous souhaitez valider ces fichiers dans votre branche actuelle. Parfois, il se peut que vous ne souhaitiez pas valider certains fichiers afin que ces fichiers ne soient pas organisés pour la validation.

Par exemple: - certaines configurations par défaut qui sont spécifiques à votre système, vous pouvez donc ne pas vouloir valider ces fichiers de configuration dans la branche où tout le monde les utilise. J'espère que cela efface votre doute! :-)

Answer 4

La zone de mise en place est comme un espace de brouillon, c'est là que vous pouvez git add La version d'un fichier ou plusieurs fichiers que vous souhaitez enregistrer dans votre prochain commit (en d'autres termes dans la prochaine version de votre projet).

Notez que vous pouvez copier des versions de fichiers dans la zone de transfert et les retirer hors de la zone de transfert avant de faire votre commit, c'est pourquoi je l'ai appelé un espace de brouillon.

La commande git add copie la version de votre fichier de votre répertoire de travail vers la zone de transit.

(Il s'agit d'une idée fausse courante, les gens peuvent penser dans leur modèle mental que le fichier est déplacé mais en réalité il est copié .)

Parcours d'un fichier pour en ajouter une version mise à jour à votre référentiel:

• 1️⃣Il est édité dans votre répertoire de travail. Le répertoire de travail est comme un banc de travail, c'est là que vous modifiez vos fichiers, ajoutez de nouveaux fichiers et supprimez des fichiers.
• 2️⃣Le fichier est ensuite ajouté à la zone de transit à l'aide de la commande git add
• 3️⃣Enfin, il est inclus dans le prochain commit lorsque vous utilisez la commande git commit

La bonne chose à propos de pouvoir choisir les fichiers à ajouter à la zone de transfert et à inclure dans un commit est que vous pouvez organiser mieux votre travail de cette façon .

Vous pouvez ajouter tous les fichiers mis à jour qui sont liés à un travail et lorsque vous effectuez une validation, vous pouvez ajouter un message qui mentionne ce travail .

De cette façon, vous pouvez mieux organiser vos commits.

Cette vidéo ???? explique tout ce qui précède d'une manière très simple et visuelle, donc cela peut être utile!

p.s. Une autre petite friandise, au cas où quelqu'un serait curieux de savoir où se trouve réellement la zone de transit dans votre répertoire .git. Il est représenté par le fichier d'index dans votre répertoire .git!