git status qui que tout est ok alors non: quand utilsier git remote update, git fetch ou git pull?

Version imprimable

13/04/2023, 22h50
gitnoob

git status qui que tout est ok alors non: quand utilsier git remote update, git fetch ou git pull?

bonjour
quand je fais git status, j'ai ca;

Citation:

> Sur la branche main
> Votre branche est à jour avec 'origin/main'.
> rien à valider, la copie de travail est propre

mais je sais que je ne suis pas à jour car:
jour 1: je suis sur mon ordi perso, j'ai fait un commit vers le depot distant, donc là je suis forcément à jour entre mon prdi perso et le depot distant.
jour 2: depuis le pc d'un pote, j'ai cloné le dépot distant pour bosser puis j'ai fait un commit, donc je suis à jour entre l'ordi de mon pote et le dépot distant
jour 3, je reviens sur mon pc perso, je sais que je ne suis plus à jour avec le dépot disant à cause du jour 2.

or quand j'ai fais git status, j'ai donc ce qui est mis plus haut: il me dit que je suis à jour...
pourtant, quand j'ouvre un fichier, je vois bien que le travail fait le jour 2 n'est pas sur ce fichier...
pourquoi git status dit que je suis à jour?

Puis au hasard, j'ai fait un git pull, et là il me sort un message avec les fichiers qui ont été modifiés.
Puis j'ouvre un fichier et là je vois que le travail du jour 2 est bien visible.
Donc après avoir fait git pull, je suis bien à jour avec le dépôt distant.

Mais si j'avais pas fait git pull et que je me contentais de git status, j'aurais bossé sur une version de mon travail qui n'était pas la dernière…

et je crois que git remote update aurait pu m'aider me je ne sais pas dans quel cadre l'utiliser.

Un peu d'aide s.v.p. ?
14/04/2023, 02h01
Obsidian
Citation:

Envoyé par gitnoob

mais je sais que je ne suis pas à jour car:
jour 1: je suis sur mon ordi perso, j'ai fait un commit vers le depot distant, donc là je suis forcément à jour entre mon prdi perso et le depot distant.
jour 2: depuis le pc d'un pote, j'ai cloné le dépot distant pour bosser puis j'ai fait un commit, donc je suis à jour entre l'ordi de mon pote et le dépot distant
…

Mais as-tu pensé à faire git push depuis le PC du copain, après avoir fait git commit ?

Visiblement oui car tu as été en mesure de le rapatrier mais dans le cas contraire, le commit serait resté sur la machine de ton ami et le serveur n'en aurait jamais rien su. Un git status sur cette machine t'aurait alors indiqué qu'elle était « en avance de 1 commit ».

Pour rappel :
git push → « pousser » → envoyer vers le dépôt distant les modifications locales qui ne s'y trouvent pas encore (et les fusionner dans la branche distante) ;
git pull → « tirer » → rapatrier en local les modifications distantes qui ne se trouvent pas encore (et les fusionner avec la branche locale) ;

Citation:

jour 3, je reviens sur mon pc perso, je sais que je ne suis plus à jour avec le dépot disant à cause du jour 2.

or quand j'ai fais git status, j'ai donc ce qui est mis plus haut: il me dit que je suis à jour...
pourtant, quand j'ouvre un fichier, je vois bien que le travail fait le jour 2 n'est pas sur ce fichier...
pourquoi git status dit que je suis à jour?

Parce que Git ne sait pas encore que quelque chose a changé sur le serveur.

Pour le savoir, il lui faut d'abord se connecter audit serveur, puis en rapatrier l'état en une fois. Il peut alors comparer tranquillement, sur la machine locale, l'état de la branche locale et de ce qu'il sait de la branche distante et le cas échéant, t'indiquer s'il y a des différences.

Pour rapatrier l'état d'une branche distante, on utilise git fetch (« to fetch » signifiant « aller chercher » en anglais). La syntaxe complète est git fetch <dépot> <refspec> mais si tu l'utilises tout seul et que ta branche courante est configurée pour suivre une branche distante (par exemple si master est faite pour suivre origin/master), alors cette commande mettra automatiquement à jour l'état connu de cette branche distante, ainsi que son contenu. Tu peux également saisir git fetch --all pour rapatrier l'état de toutes les branches distantes sans avoir à les préciser une par une.

Sache qu'un git pull est exactement équivalent à un git fetch suivi d'un git merge. Donc, dans la situation par défaut, on rapatrie d'abord le contenu origin/merge, puis l'on fusionne [C]origin/master[C] avec master (notre branche locale).

Pour résumer :
- git fetch --all pour récupérer l'état de toutes les branches distantes (et pouvoir utiliser git status ensuite) ;
- git log --oneline master...origin/master pour comparer facilement deux branches et voir ce qui est propre à l'une ou à l'autre ;
- git pull pour intégrer les nouveaux commits distants.
Citation:

et je crois que git remote update aurait pu m'aider me je ne sais pas dans quel cadre l'utiliser.

C'est une commande un peu plus large qui te permet de mettre à jour les dépôts, donc effectuer les fetches nécessaires ainsi que d'autres opérations comme l'élagage des branches mortes. C'est la manière normale de travailler sur de gros projets avec plusieurs dépôts, mais au stade où tu en es, tu peux utiliser invariablement git remote update ou git fetch --all.
14/04/2023, 09h05
gitnoob

merci
je pense avoir compris.

enf ait, j’imaginais git comme une onedrive, et donc qu'il sait forcément quelle sont les MAJ qui a eu lieu.

mais mon cas montre que c'est pas le cas, le poste A ne peut pas savoir que j'ai fait une modif sur le dépot distant depuis le poste B quoi...

Quand tu dis git fetch indique l'état: c'est juste une description de ce qui a été modifiée c'est ca?

je comprends que si je fais git pull sans faire git fetch, c'est risqué car je risque de rapatrier des choses que je ne maitrise pas...( genre quelqu'un qui a MAJ de fichiers à mon insu, je récupère toutes ces modifs, sans savoir ce qui a a été fait)
14/04/2023, 10h53
gitnoob

je viens de faire un test sur le pc de mon pote et je pense que j'ai compris:

pour rappel du début de mon histoire:
jour 1: je suis sur mon ordi perso, j'ai fait un commit vers le depot distant, donc là je suis forcément à jour entre mon prdi perso et le depot distant.
jour 2: depuis le pc d'un pote, j'ai cloné le dépot distant pour bosser puis j'ai fait un commit, donc je suis à jour entre l'ordi de mon pote et le dépot distant
jour 3, je reviens sur mon pc perso, je sais que je ne suis plus à jour avec le dépot disant à cause du jour 2. j'ai fait git push, ce qui m'a mis à jour avec le dépot distant. (et les messages précédents mont expliqué pourquoi).

maintenant, jour4: je suis allé sur le pc de mon pote qui n'est donc plus à jour avec le dépot distant.
je fait git status: il me dit que c'est à jour car il ne sait pas qu'il y a eu des modif sur le dépot distant.
je fait git fetch pour connaitre l'état, il me sort ca:

Citation:

$ git fetch
remote: Enumerating objects: 27, done.
remote: Counting objects: 100% (27/27), done.
remote: Compressing objects: 100% (16/16), done.
remote: Total 19 (delta 3), reused 19 (delta 3), pack-reused 0
Unpacking objects: 100% (19/19), 9.38 KiB | 99.00 KiB/s, done.
From https://github.com/USERXXXX/MON_PROJET
aa398c7..6af4763 main -> origin/main

ouis je fait git status et il me dit que je suis 1 commit behind.
tout ca est normal et je comprends maintenant.

ma question: si je fais simplement git pull, il me rapatrie les dernieres modifs et je suis à jour.
mais comment je peux faire pour connaitre les différences entre ce qu'il y a chez mon pote et ce qu'il y a en distant pour voir si je veux vraiment tout rapatrier?
14/04/2023, 23h40
Obsidian
Bonjour,
Tu arrives au point où il va falloir te former proprement à Git pour éviter de prendre de mauvaises habitudes, dont il serait difficile de se débarrasser ensuite. Je te conseille donc :
- La FAQ Git chez nous : https://alm.developpez.com/faq/git/
- Pro Git : en français https://git-scm.com/book/fr/v2 ou en version originale : https://git-scm.com/book/en/v2 (disponible en version papier)
- Learn Git Branching : https://learngitbranching.js.org/?locale=fr_FR pour faire des exercices en s'amusant.
Citation:

Envoyé par gitnoob

enf ait, j’imaginais git comme une onedrive, et donc qu'il sait forcément quelle sont les MAJ qui a eu lieu.

Oui, c'est une erreur classique. Il faut se souvenir que la mission première de Git est le versioning, c'est-à-dire le suivi des versions d'un logiciel ou d'un autre projet, tout comme peut l'être celles des autres logiciels similaires comme CVS, SVN, Mercurial, Bitkeeper, Fossil ou autres.

Comme Git est particulièrement efficace du côté de l'échange de ses fichiers, beaucoup de gens s'en servent effectivement comme un simple gestionnaire de dépôt distant et, par conséquent, ratent complètement l'aspect versioning de la chose alors que c'est précisément pour éviter d'avoir à gérer des dépôts à la main que ces logiciels ont été mis au point et qu'on nous les fait apprendre.

De plus, les premiers outils du genre, comme CVS, étaient centralisés et exigeaient, pour fonctionner, d'être effectivement en relation avec un serveur, fût-il hébergé sur la même machine. On s'est assez vite débarrassé de cette contrainte mais les développeurs les plus anciens peuvent croire que c'est toujours une nécessité.

Par ailleurs, Git est « acentralisé », ce qui signifie qu'il n'y a pas de dépôt de référence à proprement parler. Chaque dépôt peut soit travailler tout seul, soit être en relation avec un ou plusieurs autres dépôts distants qui ont le même statut que lui. L'utilisateur de chaque dépôt pouvant alors décider à sa convenance d'envoyer du contenu vers l'un d'eux ou d'en rapatrier dans le sien. Ceci étant posé, la manière la plus naturelle de travailler reste quand même d'adopter un modèle en étoile avec un serveur central (comme cela se fait avec pratiquement tous les autres logiciels de versioning) mais ce n'est pas une obligation technique.

Citation:

mais mon cas montre que c'est pas le cas, le poste A ne peut pas savoir que j'ai fait une modif sur le dépot distant depuis le poste B quoi...
Quand tu dis git fetch indique l'état: c'est juste une description de ce qui a été modifiée c'est ca?

Non, justement, pas avec Git.
- En premier lieu, origin est le nom donné par défaut par Git au dépôt distant lorsque tu appelles git clone, mais ce n'est pas une obligation. Tu peux renommer ce dépôt si tu le souhaites et tu seras même obligé de choisir des noms si tu ajoutes plus d'un dépôt distant au tien ;
- Ensuite, s'il y a un dépôt local (chez toi) et un dépôt distant (sur le serveur), ils vont être chacun doté d'au moins une branche, en général master. Cela veut dire qu'il y aura une branche master dans ton dépôt local et une branche master sur le serveur distant. Comme ce sont deux sites distincts, il s'agira également de deux branches indépendantes (a priori) ;
- De ton côté, comme tu as déclaré un dépôt distant, Git va gérer une copie locale des branches distantes en plus des tiennes. De ton côté, master sera donc ta propre branche et origin/master la copie de la branche master du serveur. Chaque fois que tu appelleras git fetch ou une commande assimilée, la copie locale origin/master sera mise à jour pour refléter l'état exact de la branche master du serveur et, s'il y a lieu de le faire, son contenu entier sera également rapatrié. Ça peut être long la première fois, mais ça se fait au clonage. Ensuite, Git ayant à sa disposition l'essentiel de la branche distante, il est capable de vérifier par lui-même ce qui lui manque à la mise à jour et de n'aller chercher que cela.
Donc, à partir du moment où Git dispose d'une copie conforme d'une branche distante, il lui est aussi facile de comparer cette copie avec la tienne que s'il comparait deux branches locale. Mieux : tu peux toi-même explorer origin/master comme une branche locale pour savoir où en est le serveur, sans que cela impacte directement ton travail.

Comme expliqué dans un précédent commentaire, git pull est équivalent à git fetch suivi de git merge. Donc fetch rapatrie l'état de la branche distante dans sa copie locale, et merge fusionne le contenu de cette copie dans ta propre branche.

C'est là que les choses deviennent intéressantes : est-ce à dire que Git maintient de fait tout le contenu en double (le même sur master et sur origin/master) ? → Non.

Git utilise en fait un système d'objets. Chaque objet est un fichier, comprimé avec ZLib, et nommé d'après la somme SHA1 de son contenu. Donc, s'il arrive que le serveur et ton dépôt local poussent exactement le même fichier sans le savoir (cela peut arriver souvent, par exemple si les deux parties utilisent une même image ou une même bibliothèque populaire), les contenus de ces deux fichiers vont être identiques, avoir de fait la même somme SHA1 et, in fine, finir dans un seul objet sur ton disque qui sera référencé depuis différentes positions dans ton historique.

Il se trouve que les commits fonctionnent eux-mêmes de la même façon. En fait, il y a quatre types d'objets : commit, tree (arborescence de fichiers), blob (contenu des fichiers) et tag (tags annotés uniquement, pas pour les tags légers ordinaires). Un objet commit ne contient en fait que quelques lignes de texte, indiquant l'auteur, la date, et le titre et le descriptif du commit saisi par la personne qui l'a produit, ainsi qu'une référence vers un objet tree qui décrit la liste des fichiers que la révision concernée contient et — surtout — une référence vers un autre commit (sauf bien sûr commit initial), le commit parent : celui qui était le dernier en date sur la branche avant que l'on en rajoute un.

Ça veut dire qu'une branche n'est pas un gros fichier qui contiendrait l'ensemble des amendements portés à un fichier, comme cela fonctionne avec CVS et Mercurial, par exemple. L'historique entier est ici constitué par les références successives des commits à leurs prédécesseurs, formant ainsi une grande liste chaînée et même un graphe. Les branches ne sont alors plus que des étiquettes pointant une position particulière dans ce graphe (et les tags fonctionnent de la même façon).

Tu peux t'en convaincre en explorant .git/refs/heads. Tu y trouveras des fichiers correspondant chacun à une de tes branches, et chaque fichier contient en tout et pour tout 40 caractères (+ retour à la ligne) correspondant à la somme SHA1 du commit qu'elles pointent.

On comprend alors mieux ce qui est indiqué lors d'un git fetch. Git examine d'abord les références pointées par les branches distantes et vérifie s'il dispose des objets concernés, puis remontent ces références récursivement pour vérifier s'il dispose bien de leur parents, grands-parents, etc. Chaque fois qu'il en manque un, Git l'ajoute sur une liste et une fois le processus terminé, télécharge en une fois tous les objets qui lui manquent pour compléter son édifice (et seulement ceux-là). Une fois ce téléchargement effectué, il suffit simplement de mettre les étiquettes à jour côté local.

Là encore, si les nouveaux commits n'ont eu lieu que du côté serveur, alors en remontant l'historique, on va retomber sur la révision sur laquelle pointe actuellement ta branche locale. Dans ce cas, il suffira à Git de mettre cette branche à jour pour lui dire de pointer désormais le dernier commit en date. C'est ce que l'on appelle « l'avance rapide » ou fast-forward. S'il n'y a de nouveaux commits que de ton côté, il n'y a rien à faire. S'il y a eu des nouveaux commits des deux côtés depuis la dernière fois que les branches ont été mises à jour, alors il faudra les fusionner.

Dans ce dernier cas, une fois de plus, soit les commits respectifs travaillent de leur côté sans se marcher sur les pieds et la fusion sera transparente, soit Git te demandera de résoudre les conflits.

Citation:

je comprends que si je fais git pull sans faire git fetch, c'est risqué car je risque de rapatrier des choses que je ne maitrise pas...( genre quelqu'un qui a MAJ de fichiers à mon insu, je récupère toutes ces modifs, sans savoir ce qui a a été fait)

Non, pas tout-à-fait : git pull implique forcément git fetch, donc il est inutile d'appeler les deux.

Il faut savoir qu'un certain nombre de commandes comme pull, clone, commit ou checkout existent depuis au moins CVS ou RCS, c'est-à-dire depuis l'aube des logiciels de versioning. Ça veut dire qu'elles servent en principe à la même chose dans tous ces logiciels, mais que chacun d'eux les implémente différemment en fonction du modèle qu'ils ont choisi d'adopter. Donc tu peux trouver des logiciels avec une commande pull sans commande fetch mais pour Git en particulier, le système exige qu'elle existe.

Citation:

Envoyé par gitnoob

je viens de faire un test sur le pc de mon pote et je pense que j'ai compris:

pour rappel du début de mon histoire:
jour 1: je suis sur mon ordi perso, j'ai fait un commit vers le depot distant, donc là je suis forcément à jour entre mon prdi perso et le depot distant.

Attention : il faut d'abord faire commit pour enregistrer ses modifications sur sa branche, puis faire push pour envoyer le contenu de sa branche vers le dépôt distant. Ce sont deux opérations distinctes et indépendantes.

Citation:

jour 2: depuis le pc d'un pote, j'ai cloné le dépot distant pour bosser puis j'ai fait un commit, donc je suis à jour entre l'ordi de mon pote et le dépot distant

Pas tout-à-fait : tu es jour au moment où tu fais git clone. Si tu as développé et enregistré un nouveau commit avec git commit, il faut ensuite l'envoyer au serveur avec git push, sinon comme expliqué au-dessus, il va rester sur la machine de ton ami et le serveur ne le saura jamais.

Citation:

jour 3, je reviens sur mon pc perso, je sais que je ne suis plus à jour avec le dépot disant à cause du jour 2. j'ai fait git push, ce qui m'a mis à jour avec le dépot distant. (et les messages précédents mont expliqué pourquoi).

Ce serait git pull qu'il aurait fallu faire à ce moment-là.

Attention, il y a un piège : si tu as uniquement fait git push, tu as effectivement fusionné le contenu de ta branche locale avec la branche distante du serveur, mais tu n'as pas fait l'inverse, même si, en effet, Git aura dû faire un fetch sur origin/master pour procéder à l'opération. Donc le serveur contient bien les commits des jours 1, 2 et 3 mais ta branche locale, elle ne contient que les jours 1 et 3. Il lui manque le commit fait au jour 2 sur la machine tierce. Et c'est justement git pull qui va te permette de l'y intégrer.

Citation:

maintenant, jour4: je suis allé sur le pc de mon pote qui n'est donc plus à jour avec le dépot distant.
je fait git status: il me dit que c'est à jour car il ne sait pas qu'il y a eu des modif sur le dépot distant.

En effet.

Citation:

je fait git fetch pour connaitre l'état, il me sort ca: […]

Ce sont les fameux rapatriements d'objets exposés ci-dessous. À noter que non seulement il ne va télécharger que ce qui lui manque, mais qu'il est capable d'optimiser l'opération s'il a les infos suffisantes, en ne téléchargeant que le différentiel et en les résolvant en local.

Citation:

ouis je fait git status et il me dit que je suis 1 commit behind.
tout ca est normal et je comprends maintenant.

ma question: si je fais simplement git pull, il me rapatrie les dernieres modifs et je suis à jour.
mais comment je peux faire pour connaitre les différences entre ce qu'il y a chez mon pote et ce qu'il y a en distant pour voir si je veux vraiment tout rapatrier?

En principe, vous travaillez sur des branches homologues (master partout) car en réalité, vous êtes censés travailler sur la même branche. Dans cette situation, tu devrais toujours tout rapatrier pour synchroniser leurs états, sinon elles finiraient par diverger et ce ne serait alors plus les mêmes branches.

Mais en effet, pour savoir ce qui va sortir ou ce que l'on s'apprête à faire entrer (équivalents de hg outgoing ou hg incoming sous Mercurial), il suffit de comparer des branches. En fait, après les avoir d'abord mises à jour avec fetch, tu vas simplement comparer master et origin/master comme si tu comparais deux branches locales, pour savoir ce qui est propre à l'une ou à l'autre.

Pour cela, tu peux lire la man page gitrevisions qui t'explique en détails comment spécifier des révisions de toutes les façons possibles… mais c'est un peu lourd à digérer en une fois !

Retiens simplement sous Git, que quelque soit la commande (lorsque cela a du sens de les spécifier ainsi, bien sûr), l'expression « a..b » (avec deux points) permet de demander la liste de « toutes les révisions qui sont accessibles depuis b mais pas depuis a. » Donc si a et b sont sur une même branche mais que b est en avance sur a, tu vas bien récupérer uniquement les commits qui lui sont propres.

L'expression « a...b » (avec trois points) permet, elle, de récupérer toutes les révisions qui sont accessibles depuis a ou depuis b, mais pas depuis les deux. Utile lorsque deux branches divergent et que l'on veut savoir quels sont les commits qui sont propres à chacune d'elles.

Une fois que l'on sait cela, la manière normale de comparer l'état local et l'état distant consiste à écrire :
Code:

1 2 3 git fetch --all git log master..origin/master
Tu peux ajouter l'option --oneline juste après git log pour n'afficher que les titres des commits et pas leur contenu complet à chaque fois.
15/04/2023, 23h31
gitnoob

merci beaucoup