Discussion :

[gitnoob]

Bonjour
j'ai une branche main, ok jusque là.
j'ai créé une branche où j'ai modfié le code.

puis j'ai mergé cette branche avec main en faisant une pull request avec github.

quand je retourne sur mon poste, que je me place sur la branche main, et que je supprime la branche où j'ai fait mes modifs, mon code avec toutes les modis n'est dont plus en local n'est ce pas?

je me retrouve avec le code qu'il y a sur main, mais qui n'inclut pas toutes les modifs (le code à jour est sur le déport distant, que je n'ai pas encore récupéré si j'ai bien compris)

pour le récupérer, je dois faire git pull c'est ca?

or là quand je fais git status, (sans faire git pull, je précise), git me dit que je suis à jour.
bizarre non?
Quand je regarde le code, je ne vois pas mes modifs.

puis si je fais git pull, là je vois que git rapatrie ce qu'il y asur le depot distant et mon code en local est bien à jour

pourquoi git a dit que j'étais à jour avant d'avoir fait git pull alors?

[Obsidian]

Bonjour,

puis j'ai mergé cette branche avec main en faisant une pull request avec github.

Première question : la fusion a-t-elle bel et bien eu lieu du côté de Github ou ta branche secondaire est-elle toujours à l'état de « pull request » ? Comme son nom l'indique, une pull request est une « requête en intégration » de la part d'un tiers. C'est ensuite à l'administrateur du dépôt Github (toi) d'accepter ou de refuser cette demande.

Si la fusion a eu lieu, il faut également vérifier si elle s'est faite en fast-forward (--ff) ou pas (--no-ff).

quand je retourne sur mon poste, que je me place sur la branche main, et que je supprime la branche où j'ai fait mes modifs, mon code avec toutes les modis n'est dont plus en local n'est ce pas?

Ce n'est pas entièrement vrai. Il n'est certes plus référencé si tu ne l'as pas fusionné, mais s'il y a des tags dessus, par exemple, il va rester accessible. Et même si toute référence le concernant est supprimée, le garbage collector observera tout de même un délai de quelques mois avant de le supprimer, ce qui te permet de retrouver « facilement » ton travail si jamais tu l'effaces par accident.

C'est pour cela que c'est toujours une bonne idée de commiter souvent avec Git.

je me retrouve avec le code qu'il y a sur main, mais qui n'inclut pas toutes les modifs (le code à jour est sur le déport distant, que je n'ai pas encore récupéré si j'ai bien compris)

Oui, si la fusion a bien eu lieu, là encore.

pour le récupérer, je dois faire git pull c'est ca?

or là quand je fais git status, (sans faire git pull, je précise), git me dit que je suis à jour.

Si c'est SANS faire git pull, c'est normal.

git status ne fonctionne qu'en local. Si tu veux te comparer à un site distant (le serveur), tu dois d'abord récupérer l'état de ce dernier. C'est en principe le rôle de git fetch (« fetch » signifiant « aller chercher »). Lors de cette opération, Git se connecte au serveur distant, et examine l'état des branches qui s'y trouvent. S'il constate qu'elles ont varié par rapport à la dernière fois qu'il l'a fait, il va mettre à jour ses propres fiches le concernant, soit en l'état toutes les branches qui sont marquées remote/…. Et s'il constate qu'elles pointent vers des objets qu'il ne possède pas encore en local, alors Git va rapatrier ces objets également, mais ne va pas les fusionner tout de suite avec tes branches locale. Autrement dit : Git tient des copies locales des branches distantes.

Et en fait, Git ne travaille jamais directement avec l'extérieur. Chaque fois qu'il prétend le faire, il s'appuie en fait sur les copies locales qu'il en a faites et qui servent à ça. Ces copies ne sont donc mises à jour que lorsque tu effectues un git fetch (éventuellement avec --all) pour aller les chercher, ou plus généralement avec git remote update qui sert à ça également, mais de façon plus générale (mise à jour de tous les status, gestion des branches mortes, etc.).

Une fois que c'est fait, Git synchronise une branche locale avec une branche distante en les fusionnant, c'est-à-dire en effectuant un git merge entre la branche locale et la branche distante. La plupart du temps, les branches ne divergent pas. Il y en a simplement une qui est en retard sur l'autre et dans ce cas, on peut faire une fusion en avance rapide (fast-forward) qui consiste simplement à rapatrier les objets manquants sur la branche en retard de façon à ce qu'elles redeviennent identiques.

Ce qui nous permet enfin de boucler la boucle : sous Git en particulier, git pull est l'équivalent de git fetch suivi de git merge.

bizarre non? Quand je regarde le code, je ne vois pas mes modifs.
puis si je fais git pull, là je vois que git rapatrie ce qu'il y asur le depot distant et mon code en local est bien à jour

pourquoi git a dit que j'étais à jour avant d'avoir fait git pull alors?

Pour les raisons exposées ci-dessus : Git ne se synchronise avec un serveur distant que si on lui demande de le faire ou lorsque c'est nécessaire dans le cas de git pull. Lorsqu'il le fait, il ouvre une connexion, rapatrie ce dont il a besoin, synchronise ses copies locales pour refléter l'état du serveur distant et referme la connexion. Tout le reste est ensuite effectué depuis ces copies locales.

[gitnoob]

Première question : la fusion a-t-elle bel et bien eu lieu du côté de Github ou ta branche secondaire est-elle toujours à l'état de « pull request » ? Comme son nom l'indique, une pull request est une « requête en intégration » de la part d'un tiers. C'est ensuite à l'administrateur du dépôt Github (toi) d'accepter ou de refuser cette demande.

oui la fusion a bien eu lieu


je comprends que me confusion vient de la distinction serveur distant et serveur local
j'ai toujours du mal à me dire que les 2 ne sont pas synchro de maniere systématique et j'ai toujours l'impression que je bosse directement avec le serveur distant.

merci, je commence à comprendre