Lecture du contenu d'un fichier dans Git

Bonjour,
Je débute en Git et veuillez m'excuser si cette question est ennuyeuse du fait de sa banalité élémentaire.
Après lecture de quelques tutoriels sur Git (que j'ai mal compris sans doute car je les trouve souvent trop condensés) je veux introduire un 1er fichier, ex fichier1.txt:

• J'écris ce fichier sur un éditeur de texte courant auquel je suis habitué.
• Comment l'introduire dans Git pour pouvoir passer la 1ère commande touch? c-à-d aller de mon éditeur de texte à Git?
• J'exécute les commandes classiques suivantes: add et commit, j'obtiens mon 1er commit.
• Je veux relire ce fichier à l'écran: comment? Quelle commande Git?
• Je veux faire une autre modification du contenu de ce fichier: comment? où?
• Comment introduire cette modification dans Git?

Merci pour vos réponses.

Bonsoir et bienvenue (au moins sur le forum Git, car en fait ton compte est ancien ;) ).

Nous allons tenter de te répondre, par contre je ne sais pas ce qu'est une « commande touch » (hormis bien sûr la commande « touch » d'un Shell Unix) ni ce que tu entends par « aller de mon éditeur de texte à Git ». Git est le logiciel de versioning en lui-même. Il est fait pour s'utiliser avec une ligne de commande depuis ton répertoire de travail mais bien souvent, on le retrouve intégré dans des IDE tels que VSCode et/ou associés à des outils qui en enrichissent les fonctions. Donc il est possible que tu te réfères en fait à l'un d'eux. Mais quoi qu'il en soit :

Citation:

---

Comment l'introduire dans Git pour pouvoir passer la 1ère commande touch? c-à-d aller de mon éditeur de texte à Git?

---

En principe, la toute première fois, on commence par initialiser le répertoire dans lequel on veut travailler grâce à git init. Ceci ajoute en réalité un répertoire caché « .git » à l'endroit où tu trouves lorsque que tu appelles cette commande, lequel va contenir tous les fichiers de travail de Git et l'historique de ton dépôt. Cela permet aussi à Git de savoir qu'il s'agit bien d'un dépôt et d'en retrouver le sommet. Avantage : il est possible d'initialiser un dépôt Git même si le répertoire contient déjà des fichiers.

Sinon, comme tu le dis juste après, on ajoute le fichier avec git add <tonfichier> et quand tout est prêt, on fait git commit. Son fonctionnement est très similaires aux autres logiciels du mêmes types mais avec deux ou trois subtilités qui en changent l'approche et qui le rendent particulièrement efficace.

Citation:

---

J'exécute les commandes classiques suivantes: add et commit, j'obtiens mon 1er commit.
Je veux relire ce fichier à l'écran: comment? Quelle commande Git?

---

Il n'y a rien à faire de particulier dans un premier temps. Il te suffit simplement de ré-ouvrir ce fichier avec ton éditeur de texte. En fait, tu peux même le laisser ouvert, ça ne posera pas de problème.

Ce qu'il va se passer, en réalité, c'est que Git va se comporter comme un observateur de l'état de ton dépôt. Tu peux utiliser git status à tout moment pour savoir où tu en es. Si aucune modification n'a eu lieu depuis ton dernier commit, il te dira que ton dépôt est propre. Si tu as ajouté de nouveaux fichiers qu'il ne connaît pas encore, il te les affichera en rouge avec le status « untracked ». S'il y a de nouvelles modifications sur des fichiers connus, il t'affichera également ceux-ci en rouge avec le status « unstaged » et si tu viens d'ajouter ces modifications pour commit avec git add, il te les affichera en vert avec le statut « staged ».

Citation:

---

Je veux faire une autre modification du contenu de ce fichier: comment? où?

---

Même chose : directement sur le fichier du dépôt avec l'éditeur de ton choix. Comme expliqué au-dessus, Git va se comporter en observateur et il te dira si ton fichier diffère ou non de la dernière chose enregistrée en date. C'est toi, ensuite, qui choisit de commiter ou non tes modifications.

Citation:

---

Comment introduire cette modification dans Git?

---

Alors : on refait git add <tonfichier> puis git commit. Un nouveau commit est créé, qui suit immédiatement le dernier en date et ta branche est mise à jour pour indiquer qu'il en est désormais l'extrémité.

Pourquoi faut-il refaire git add <fichier> ? C'est là que Git adopte une approche extrêmement intelligente : comme tous les SCM avant lui, Git utilise un « index » pour faire la liste des fichiers qu'il suit et laisser tous les autres inchangés, même s'ils sont dans le même répertoire. C'est donc cet index (qui au départ n'est qu'une liste de fichiers, à plat) que l'on enrichit avec git add. MAIS il va faire bien mieux que simplement ajouter ce nom : il va également leur associer, à chaque appel à git add le contenu du fichier ciblé. Si bien qu'en faisant cela, on prépare en réalité, fichier par fichier, ce qui formera le contenu du commit final et lorsque celui a lieu avec git commit, il suffit en fait à Git d'enregistrer l'état actuel de l'index.

Par ailleurs, il faut savoir que Git est un système à snapshot : il n'enregistre pas les différences entre les fichiers, mais le contenu entier du fichier à chaque fois. Et ce dans un « objet » qui est ensuite nommé d'après la somme SHA1 de ce contenu. Si bien que si l'on ré-enregistre intégralement un fichier même s'il n'a changé que d'un ou deux octets, on n'enregistre en revanche jamais de copie intégrale d'un même contenu (justement à cause de cette somme, qui permet de savoir très vite si on l'a déjà ou pas).

Et par conséquent, c'est justement en comparant les versions d'un fichier donné contenues de l'index, dans le dernier commit et dans ton répertoire de travail que Git peut savoir où il en est :
— Index, commit pointé et répertoire de travail tous identiques (pour un fichier donné) → le dépôt est propre ;
— Index et commit identiques mais répertoire différent → tu as fait des modifications (unstaged). Il faut les ajouter ;
— Commit différent mais index et répertoires identiques → tu as fait des modifications et tu les as ajoutées à l'index avec git add. Elles seront enregistrées dans le prochain commit.

Autre point important : git ne s'appuie que sur le contenu pour savoir si un fichier a reçu ou non des modifications. Il ne s'appuie notamment pas sur la date de modification du fichier, qui n'est d'ailleurs pas toujours disponible (en revanche, il s'en sert quand même pour savoir si ça vaut le coup de vérifier un fichier. Et cette décision peut d'ailleurs être déléguée à un outil tiers). Ça veut dire que si tu fais une modification à un fichier, tu la verras apparaître dans git status. Si tu supprimes cette modification, ton fichier retrouve son état antérieur et ton dépôt redevient propre, sans que Git ait à se souvenir de quoi que ce soit.


Pour naviguer à travers les différents commits, par la suite, tu pourras utiliser git checkout mais attention à bien revenir au sommet de ta branche avant d'apporter de nouvelles modifications à tes fichiers. Si tu le fais quand même, il y a bien sûr moyen de composer avec, mais cela demande de bien maîtriser l'outil d'abord.

Bonjour,
Pour commencer je tiens à dire que ce problème est RESOLU par la longue réponse de Obsidian mais je veux répondre tout de même car tard dans la nuit je me suis aperçu la grosse erreur que j'ai faite en envoyant ce message dans le forum: j'ai compris qu'il faut séparer ce travail de lecture de contenu d'un fichier du rôle de Git, cette lecture revient à un éditeur de texte, logiciel extérieur à Git que l'on peut appeler à tout moment).
Dès ce matin de bonne heure j'ai voulu répondre sur le forum pour dire aux membres du forum d'ignorer totalement ce message mais grande fut ma surprise en recevant très tôt la réponse de Obsidian.
En réalité je suis un vieux membre du Forum mais peu actif; j'avais travaillé surtout sur Java et c'est tout à fait par hasard que je tombe sur Git et GitHub: c'est donc avec un regard d'un débutant que j'ai abordé ce sujet qui semble me plaire (d'où probablement ces confusions de vocabulaire dus aussi au passage anglais-français).
Merci Obsidian pour cette réponse rapide mais très détaillé qui complète énormément ce que je n'ai pas réussi à trouver dans quelques tutoriels sur Git et GitHub (il faut avouer que ce n'est pas possible pour un débutant normal, à moins d'être très brillant d'avoir le minimum de connaissances en si peu de temps sur un sujet tel que Git par exemple).
Pour terminer je recommande aux débutants sur Git de bien lire ce post-réponse de Obsidian que je trouve très lisible.
Encore une fois merci.

Bonjour et merci pour ton retour ! Ils sont toujours très appréciés des intervenants.

Citation:

---

Envoyé par Snaval

En réalité je suis un vieux membre du Forum mais peu actif; j'avais travaillé surtout sur Java et c'est tout à fait par hasard que je tombe sur Git et GitHub: c'est donc avec un regard d'un débutant que j'ai abordé ce sujet qui semble me plaire (d'où probablement ces confusions de vocabulaire dus aussi au passage anglais-français).

---

C'est aussi très utile lorsque l'on transmet son expérience car il arrive régulièrement qu'une personne aborde la chose sous un angle très peu fréquent et cela suffit pour que l'on ne comprenne pas comment elle voit les choses. C'est alors appréciable de pouvoir l'ajouter à sa base de connaissance car en général, une fois remise « dans le bon sens », tout le reste se débloque automatiquement.

Java est aussi un bon exemple : normalement, on peut l'exploiter comme du C et tout faire depuis une ligne de commande, mais la plupart des gens ces dernières années utilisaient Eclipse et NetBeans avant ça. Donc on a l'habitude de tout avoir dans l'IDE. Pour l'anecdote, j'ai fait l'inverse au travail : j'ai repris une très vieille application développée de la sorte sous Windows dans le courant des années 2000 et je l'ai épurée pour la maintenir sur une plateforme Linux, débarrassée de toutes ses dépendances. Et utiliser Git a été très utile pour mener cette migration sans se perdre.

Citation:

---

Merci Obsidian pour cette réponse rapide mais très détaillé qui complète énormément ce que je n'ai pas réussi à trouver dans quelques tutoriels sur Git et GitHub (il faut avouer que ce n'est pas possible pour un débutant normal, à moins d'être très brillant d'avoir le minimum de connaissances en si peu de temps sur un sujet tel que Git par exemple).

---

En fait, c'est souvent le cas mais Git « souffre » en plus d'un problème particulier : il y a l'air absolument cryptique tant que l'on n'a pas saisi les deux ou trois concepts fondamentaux alors qu'en réalité, une fois qu'on les a compris, non seulement ils paraissent très simples en eux-mêmes mais absolument tout le reste s'éclaircit tout seul également, et on en arrive généralement à la conclusion qu'il n'y a probablement pas de modèle meilleur. C'est pour ça que j'ai mis le doigt dessus dans mon post (et pourquoi il s'étend un peu).

C'est dommage car cela pousse généralement les gens vers d'autres solutions (telles que Mercurial) qui paraissent beaucoup plus accessibles de prime abord et « qui leur suffisent bien pour ce qu'ils en font » mais qui plafonnent ensuite très vite dès lors que l'on gagne en expérience. Il est alors assez difficile de faire la migration inverse.

Donc, comme exposé, mettre en lumière :

• L'approche par snapshot
• Le système d'objets (quatre types uniquement)
• Le fonctionnement de l'index

… et ça suffit à mettre le pied à l'étrier. On peut ensuite insister sur le modèle en graphe acyclique non orienté (DAG), parler du reflog (très utile), et du fait qu'il n'y a que des branches légères (pour ceux qui viennent d'un autre outil), et on est pratiquement opérationnel.

Je te conseille également d'essayer git log --graph et surtout d'adopter un outil de navigation dans l'historique tel que tig ou gitk, qui sont en fait des front-ends pour le contenu renvoyé par Git lui-même, mais qui permettent de visualiser beaucoup plus clairement ce qu'il se passe.

Citation:

---

Encore une fois merci.

---

Avec plaisir.
Bon courage et à bientôt.