Cherche des points de repère sur Git

Version imprimable

Bonjour tout le monde,

Il est temps que je m'intéresse de plus près à Git, car j'en suis arrivé au stade où j'avais un projet qui tournait bien, et dès que j'ai demandé à Git de faire quoi que ce soit ça a tout planté, le projet ne pouvait plus être exécuté.

Avec une doc sur la ligne de commandes ("Git Notes for professionals", de https://goalkicker.com/GitBook/)

j'ai pu un peu reprendre pied, et mon projet pouvait de nouveau s'exécuter.

Ensuite je me suis dit que j'allais pouvoir faire du travail propre, puisqu'en cas de fausse manœuvre je pourrais revenir au commit qui m'intéresse.

Moui, bon, ça, c'est le principe.

Mais voilà un dialogue qui ne me plaît pas des masses :
Code:

1 2 3 4 5 6 git pull 6053b253a801c95672f216b0a85ac1ddda14aaab --rebase fatal: '6053b253a801c95672f216b0a85ac1ddda14aaab' does not appear to be a git repository fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.
Je croyais restaurer un commit de mon fil principal, sur ma machine locale, et voilà qu'on me parle d'un "remote repository". D'ailleurs, je me rappelle bien que Git a automatiquement créé un "remote", mais on dirait que mon appréhension de la question gagnerait à un peu plus de précision.

Par ailleurs, je vois ici au sujet de la commande git restore que c'est une "commande expérimentale", ce qui m'a paru remettre en cause l'utilité même de Git : si on ne peut pas restaurer sur une base stable, à quoi bon sauvegarder ?

J'ai trouvé dans ce forum un fil Besoin de conseils sur l'utilisation de Git, qui m'a eu l'air d'offrir de bonnes bases. Je n'étais pas trop sûr que ce soit une bonne idée de venir à la suite pour poser des questions, alors j'ai ouvert un autre fil.

Alors j'espère que quelqu'un va pouvoir me remettre sur les rails, car après avoir lu la doc sur la ligne de commande j'ai pu ressusciter mon projet, et dès que j'ai voulu refaire une modif dessus, voilà-t-y pas qu'il est de nouveau mort, le bouton Debug, dans Visual Studio (qui porte le nom du projet en fait) est remplacé par "Attach".

Bonjour,
Citation:
Envoyé par Gluups
Mais voilà un dialogue qui ne me plaît pas des masses :
Code:

1 2 3 4 5 6 git pull 6053b253a801c95672f216b0a85ac1ddda14aaab --rebase fatal: '6053b253a801c95672f216b0a85ac1ddda14aaab' does not appear to be a git repository fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.
Je croyais restaurer un commit de mon fil principal, sur ma machine locale, et voilà qu'on me parle d'un "remote repository". D'ailleurs, je me rappelle bien que Git a automatiquement créé un "remote", mais on dirait que mon appréhension de la question gagnerait à un peu plus de précision.
En ce qui concerne les dépôts (locaux ou distants), Git est un système « acentralisé », c'est-à-dire qu'il ne dépend pas d'un serveur de référence en particulier, comme cela pouvait être le cas avec CVS. Un dépôt Git peut avoir zéro, un ou plusieurs dépôts « voisins » portés à sa connaissance depuis lesquels il peut récupérer du matériel ou en envoyer, mais ce n'est pas une obligation. Dans l'immense majorité des cas :

Soit on travaille seul sur ta machine et on initialise un nouveau dépôt Git dans un répertoire avec git init ;
Soit on récupère un projet existant en principe depuis une machine distante en réseau (mais cela pourrait tout aussi bien être un autre répertoire en local) et on fait git clone <url du dépôt>

Dans le deuxième cas, Git va automatiquement créer un sous-répertoire qui portera le nom du dépôt, l'initialiser normalement comme si on avait effectué git init dedans, y déclarer un dépôt distant connu vers l'URL spécifié et qu'il nommera origin par défaut (mais ce n'est pas une obligation non plus et cela peut être éventuellement modifié par la suite). Ce faisant, il va faire l'inventaire des branches distantes, les déclarer comme telles et rapatrier leur contenu. Enfin, il va créer au moins une branche locale (comme avec init). Soit master, soit une branche portant le nom de la branche active du dépôt distant à ce moment-là et la paramétrera pour qu'elle « suive » cette branche distante.

Rien ne t'empêche ensuite d'ajouter manuellement de nouveaux dépôts distants, ou d'en déclarer un premier si tu avais jusqu'ici initialisé ton propre dépôt avec git initLe message en question, à présent, t'indique simplement qu'il ne connaît pas de dépôt distant nommé « 6053b253a801c95672f216b0a85ac1ddda14aaab » (qui est en fait la référence d'une révision, ou d'un commit). Le dépôt doit probablement s'appeler origin mais dans tous les cas, il reste extrêmement rare d'avoir à préciser un nom de dépôt à git pull tant que l'on ne travaille pas sur un dépôt très sophistiqué.

Ce message indique surtout, en revanche, que ce n'était probablement pas la commande git pull qu'il te fallait ici, mais il va nous falloir un peu plus d'infos pour t'orienter correctement. Il s'agissait probablement de git rebase (en tant que commande à part entière, pas en tant qu'option de pull) mais là encore, prudence avant d'agir.

Citation:

Par ailleurs, je vois ici au sujet de la commande git restore que c'est une "commande expérimentale", ce qui m'a paru remettre en cause l'utilité même de Git : si on ne peut pas restaurer sur une base stable, à quoi bon sauvegarder ?

C'est la commande restore en particulier qui est expérimentale. Je ne sais pas si elle l'est toujours à cette heure, mais elle l'était parce qu'elle a été introduite relativement récemment et ce, parce que certaines personnes trouvait le jeu de commandes confus et ont proposé cette interface. En réalité, ça ne l'est que si le fonctionnement de Git (qui se résume à trois ou quatre concepts simples et très astucieux) l'est aussi. Utilisant Git avant l'apparition de cette commande, je ne l'utilise personnellement jamais, même si elle commence à être recommandée sur d'autres forums.

Citation:

Alors j'espère que quelqu'un va pouvoir me remettre sur les rails, car après avoir lu la doc sur la ligne de commande j'ai pu ressusciter mon projet, et dès que j'ai voulu refaire une modif dessus, voilà-t-y pas qu'il est de nouveau mort, le bouton Debug, dans Visual Studio (qui porte le nom du projet en fait) est remplacé par "Attach".

Les boutons de Visual Studio, c'est encore autre chose. Ce sont des facilités proposées par cet IDE mais Git lui-même en est indépendant.

Dis-en nous un peu plus pour que l'on sache si c'est un checkout, un reset ou bien un rebase qu'il te faut.

24/04/2023, 02h14
Gluups

Ah, oui. Là où la situation risque d'être le plus critique, c'est que je crains de ne pas être très à l'aise pour savoir comment m'y prendre pour donner plus d'info. J'imagine que git status ne suffit pas.

Ah oui si quand même quelques éléments. Le projet était ingérable sous Visual Studio depuis que je me suis piqué de faire un commit, alors comme j'avais reçu une doc pour la ligne de commande j'ai regardé avec ça, c'est là que je suis rendu compte que sauvegarder une ancienne version en sous-répertoire de la solution était une mauvaise idée. J'ai retiré ce sous-répertoire du dépôt Git.

Ça m'a permis d'arriver à une version compilable.

Ensuite, on dirait que j'ai lancé des add et des commit sans toujours avoir une bien bonne conscience des impacts, si certaines parties avaient un remote et d'autres pas.

Par quel bout est-ce que je pourrais bien lancer les investigations ?
24/04/2023, 14h41
Obsidian

Citation:

Envoyé par Gluups

Ah, oui. Là où la situation risque d'être le plus critique, c'est que je crains de ne pas être très à l'aise pour savoir comment m'y prendre pour donner plus d'info. J'imagine que git status ne suffit pas.

Suffire, pas sûr mais ce serait déjà beaucoup…

Citation:

Ensuite, on dirait que j'ai lancé des add et des commit sans toujours avoir une bien bonne conscience des impacts, si certaines parties avaient un remote et d'autres pas.

Normalement, cela ne doit avoir aucun impact négatif sur ton projet. Au contraire, cela te permet de revenir en arrière au besoin. Oublie les remote repositories pour le moment. Si tu initialisé ton projet en local avec git init (ou par l'intermédiaire de VSCode), il ne devrait pas y en avoir, sauf si tu stockes ton projet dans une forge logicielle telle que Github ou sur les serveurs de ta compagnie.

Citation:

Par quel bout est-ce que je pourrais bien lancer les investigations ?

On veut bien le git status pour commencer, donc. Lance ensuite git branch -vva pour avoir la liste de toutes les branches, locales et éventuellement distantes, qui sont en vigueur dans ton dépôt et donne-nous le résultat ici si tu n'y vois rien de confidentiel.

Je vois également que les Git Notes que tu nous cites sont un document intéressant, mais qu'il est fait souvent usage de pull --rebase, qui n'est pas nécessairement la manière normale d'utiliser la chose. Et si l'on s'en réfère à la man page :

Citation:

-r, --rebase[=false|true|merges|interactive]
When true, rebase the current branch on top of the upstream branch after fetching. If there is a remote-tracking branch corresponding to the upstream branch and the
upstream branch was rebased since last fetched, the rebase uses that information to avoid rebasing non-local changes.

[…]

Note
This is a potentially dangerous mode of operation. It rewrites history, which does not bode well when you published that history already. Do not use this option
unless you have read git-rebase(1) carefully.

Par ailleurs, avec quoi visualises-tu l'historique de ton dépôt ? Avec les outils intégrés de Visual Studio ou avec une autre commande ?

Quoi qu'il en soit, c'est probablement git checkout 6053b253a80 mais il te faudra au préalable sauvegarder tes modifications si tu en as fait, et vérifier sur quelle branche tu te trouves pour pouvoir y revenir ensuite.

Citation:

Envoyé par Obsidian

Suffire, pas sûr mais ce serait déjà beaucoup…

En effet on peut déjà commencer par ça ...
Code:

1 2 3 4 5 6 7 8 9 HEAD detached from 402d44f Untracked files: (use "git add <file>..." to include in what will be committed) .vsconfig Timers en vrac/ commit-6053b25 nothing added to commit but untracked files present (use "git add" to track)
Le commit-6053b25, c'est une sauvegarde que j'ai faite du commit, pour pouvoir rebaser dessus, et raté, ça a été refusé.

Timers en vrac, c'est la version sauvegardée. Pour "faire joli", car finalement je ne vois pas bien quand je vais m'y intéresser.

.vsconfig je suppose que c'est exclu automatiquement.

Citation:

Normalement, cela ne doit avoir aucun impact négatif sur ton projet. Au contraire, cela te permet de revenir en arrière au besoin. Oublie les remote repositories pour le moment. Si tu initialisé ton projet en local avec git init (ou par l'intermédiaire de VSCode), il ne devrait pas y en avoir, sauf si tu stockes ton projet dans une forge logicielle telle que Github ou sur les serveurs de ta compagnie.

Il m'avait bien semblé. Je dois avouer que ça a été une surprise quand je n'ai pu ni faire marche arrière, ni faire marche avant, ni rester sur place. Et impossible d'exécuter le projet.

Citation:

On veut bien le git status pour commencer, donc. Lance ensuite git branch -vva pour avoir la liste de toutes les branches, locales et éventuellement distantes, qui sont en vigueur dans ton dépôt et donne-nous le résultat ici si tu n'y vois rien de confidentiel.

Bon, ça c'est assez vite fait.
Code:

1 2 3 4 5 6 7 8 9 git branch * (HEAD detached from 402d44f) master git branch -vva * (HEAD detached from 402d44f) 05d5c2d Revert "Revert "Revert "aucun changement non indexé""" master a691acc [origin/master: ahead 2, behind 6] test remotes/origin/master 6d529c5 Mais qu'est-ce qu'il y a encore ?
Tiens, tout-à-coup voilà qu'au début de ma réponse Firefox ne voulait plus d'espace, il a fallu que je tape Alt 032. Une fois que j'ai fait ça la barre d'espacement fonctionne de nouveau, et d'ailleurs l'espace que j'avais tapé en vain est apparu un mot plus tard.

Citation:

Je vois également que les Git Notes que tu nous cites sont un document intéressant, mais qu'il est fait souvent usage de pull --rebase

d'ailleurs, c'est bien ce que j'ai cité au début de ma question.

Citation:

, qui n'est pas nécessairement la manière normale d'utiliser la chose. Et si l'on s'en réfère à la man page :

Bon il va falloir que je relise ça après avoir répondu, puisque ce n'est pas cité.

Citation:

Par ailleurs, avec quoi visualises-tu l'historique de ton dépôt ? Avec les outils intégrés de Visual Studio ou avec une autre commande ?

J'ai longtemps essayé avec Visual Studio, surtout qu'il m'a semblé qu'ils ont pas mal travaillé là-dessus.
Et quand je me suis dit qu'il allait falloir que je m'y plonge, comme j'avais une doc je m'en suis servi. Donc, ligne de commandes.

Tiens, d'ailleurs ça c'est amusant : dans la ligne de commandes de Windows j'ai bien Git, mais pas dans la ligne de commandes de Visual Studio.

Citation:

Quoi qu'il en soit, c'est probablement git checkout 6053b253a80 mais il te faudra au préalable sauvegarder tes modifications si tu en as fait, et vérifier sur quelle branche tu te trouves pour pouvoir y revenir ensuite.

OK.
Je dois avoir une sauvegarde du disque, mais ça me paraît plus prudent d'en refaire une du répertoire. Et sur un autre disque, du coup.
D'ailleurs, ce numéro ce sont les caractères qui tiennent dans la ligne sur log --oneline, mais git ne connaît rien à cette adresse, il lui faut le numéro entier, qu'on trouve dans git log, sans --oneline.

Et encore, ça ne lui va pas à tous les coups.

Bon alors puisque je mentionnais des curiosités d'installation ...

La ligne de commandes de git ne répondait plus alors je l'ai réinstallée. Ce faisant j'ai consacré deux à trois heures à choisir un éditeur, j'ai choisi VSCodium, que j'ai installé spécialement pour ça, et après ça quand je fais un commit, si j'oublie le paramètre -m, on m'affiche le fichier de message avec vim. Et là je suis d'accord avec la présentation qui en est faite, en résumé "à fuir". Et le fait est que j'ai mis un sacré bout de temps à savoir sortir de ce truc.

Code:

1 2 3 Note This is a potentially dangerous mode of operation. It rewrites history, which does not bode well when you published that history already. Do not use this option unless you have read git-rebase(1) carefully.
Ah, çà, je dois bien dire que je n'ai pas read git-rebase carefully.
Si tant est que j'y aie jeté un coup d'œil ...

Et le fait que je sois bloqué tendrait à valider le caractère dangereux de la manœuvre.

Citation:

Envoyé par Obsidian

Quoi qu'il en soit, c'est probablement git checkout 6053b253a80

Joli !
Après il a encore fallu dire à Visual Studio de recharger tous les projets (pour être sûr mais il n'y en a qu'un), et ensuite ça s'exécute.

Est-ce que c'est différent si dans l'historique sous Visual Studio je fais un clic droit sur ce commit et que je clique sur Rétablir ?
Code:

1 2 3 4 5 6 7 8 9 10 11 12 git checkout 6053b253a801c95672f216b0a85ac1ddda14aaab Warning: you are leaving 1 commit behind, not connected to any of your branches: 05d5c2d Revert "Revert "Revert "aucun changement non indexé""" If you want to keep it by creating a new branch, this may be a good time to do so with: git branch <new-branch-name> 05d5c2d HEAD is now at 6053b25 Mise à jour globale
Bon, alors j'avais obtenu ça, après j'ai voulu mettre trois instructions en commentaire et refaire un commit, et c'est là que ça a coincé.

25/04/2023, 11h32
Gluups
Alors j'ai fait quelques modifs, y compris l'intégration du projet à la solution.

J'avais ça :
Code:

1 2 3 git branch -v * Inclusionduprojet 04b26e1 Voilà master a691acc [ahead 2, behind 6] test
Et après, j'ai voulu mettre ça dans le master. Ça coince un peu.
Code:

1 2 git merge Inclusionduprojet --into master Already up to date.
Ensuite il faut que je potasse le topo sur l'utilisation de Git dans Visual Studio, parce que là où je crois dire qu'il faut garder Form1 de Inclusionduprojet, Git comprend qu'il faut supprimer purement et simplement Form1 sans se poser aucune question. .

Euh ... Ce n'est pas tout-à-fait ce que j'ai voulu dire.

1 pièce(s) jointe(s)

Citation:

Envoyé par Gluups

Le commit-6053b25, c'est une sauvegarde que j'ai faite du commit, pour pouvoir rebaser dessus, et raté, ça a été refusé.

Ça dépend tout de même de ce que tu appelles « rebaser » (et à mon avis, tous tes ennuis viennent de là au départ) : « rebaser » signifie « débrancher et une branche et aller la rebrancher à partir d'une autre position ». Et pour ce faire, Git « rejoue » tous les commits de ta branche à partir du nouveau point de départ comme si tu les y avais saisis toi-même. Et une fois que c'est fait, Git déplace le nom de la branche pour le placer au sommet de la nouvelle.

C'est une opération que l'on utilise généralement lorsque l'on développe une branche en parallèle d'une branche principale parce que les changements sont importants et qu'on ne peut pas les partager avant d'avoir fini (risque de dysfonctionnement du projet, censé être partagé) et que le travail dure un peu trop longtemps par rapport à l'évolution de la branche. Il arrive un moment où le retard est un peu trop important et où il vaut mieux re-déplacer son travail au sommet du dernier état en date du produit sur lequel on travaille. Pour procéder à cette opération, on utilise git rebase.

git pull, à présent, n'a rien à voir. Cette commande, symétrique de git push, sert simplement à importer dans sa branche courante les dernières modifications en date sur la branche homologue qu'elle suit (généralement, c'est master en local qui suit origin/master sur le serveur distant). C'est ce que l'on utilise normalement pour intégrer à sa branche de travail soit les modifications de ses collègues, soit ses propres modifications lorsqu'elles ont eu lieu sur une autre machine. Lorsque les modifications n'ont eu lieu que d'un seul côté, c'est facile : soit c'est du nôtre et il n'y a rien à faire de plus, soit c'est du côté serveur et dans ce cas, on peut les appliquer directement à la suite de l'état courant de la branche locale. Git appelle cela le fast-forward (avance rapide) car il n'y a pas besoin de procéder à une opération de fusion (sauf si on lui demande explicitement de le faire quand même).

Si des modifications ont eu lieu des deux côtés, alors Git considérera que les deux branches homologues, locale et distante, ont divergé (comprendre : ont chacun suivi leur propre chemin). Dans ce cas, il faudra les fusionner comme s'il s'agissait de deux branches différentes et éventuellement résoudre les conflits. C'est la manière normale de travailler quand on est plusieurs, et cela se passe dès que tu lances git pull. git pull --rebase, à présent, est simplement une option qui permet d'indiquer à Git de rebaser automatiquement les modifications de ton côté au sommet de la branche rapatriée et mise à jour, plutôt qu'effectuer une fusion. C'est pratique, mais ce n'est pas la manière normale de travailler, ce n'est pas toujours possible et cela ne s'utilise que lorsqu'on est déjà très à l'aise avec Git et/ou que l'on a un workflow déjà bien en place dans la structure pour laquelle on travaille.

git checkout, enfin, permet de de rappeler dans le répertoire de travail une des révisions que l'on a enregistré au cours du temps. Si tu passes un nom de branche à cette commande, Git considère que tu veux basculer sur cette branche et tu passeras en mode « attaché » (ce qui veut dire que le nom de branche sera mis à jour au fur et à mesure de tes commits), sinon tu seras en mode « détaché », c'est-à-dire lié à aucune branche. git status t'indiquera la somme SHA1 de la révision sur laquelle tu te trouves. Si tu produis un ou plusieurs commits à ce moment-là, ils seront bien enregistrés mais ne seront liés à rien tant que tu n'auras pas défini au moins un tag ou une nouvelle branche. Tu risques de les perdre la prochaine fois que tu appelleras git checkout à nouveau pour te déplacer ailleurs. Exemple :
$ git checkout <somme du commit no 3>


 (Sommet de la branche master)
 ↑
 O Commit n° 5
 |
 O Commit n° 4
 |
 O Commit n° 3  ← Tu es ici
 |
 O Commit n° 2
 |
 I Commit n° 1 (Commit initial)
Citation:
Bon, ça c'est assez vite fait.
Code:

1 2 3 4 5 6 7 8 9 git branch * (HEAD detached from 402d44f) master git branch -vva * (HEAD detached from 402d44f) 05d5c2d Revert "Revert "Revert "aucun changement non indexé""" master a691acc [origin/master: ahead 2, behind 6] test remotes/origin/master 6d529c5 Mais qu'est-ce qu'il y a encore ?
Tu as donc bien une branche master locale configurée pour suivre (« to track ») la branche distante origin/master. Tu as donc bien cloné ton projet à partir d'une source donnée (un serveur distant).

Citation:

Tiens, tout-à-coup voilà qu'au début de ma réponse Firefox ne voulait plus d'espace, il a fallu que je tape Alt 032. Une fois que j'ai fait ça la barre d'espacement fonctionne de nouveau, et d'ailleurs l'espace que j'avais tapé en vain est apparu un mot plus tard.

Ça arrive de temps en temps… :-)

Citation:

Je dois avoir une sauvegarde du disque, mais ça me paraît plus prudent d'en refaire une du répertoire. Et sur un autre disque, du coup.
D'ailleurs, ce numéro ce sont les caractères qui tiennent dans la ligne sur log --oneline, mais git ne connaît rien à cette adresse, il lui faut le numéro entier, qu'on trouve dans git log, sans --oneline.

Et encore, ça ne lui va pas à tous les coups.

Normalement, c'est le même. Git utilise des « objets » (dont les commits font partie) qui sont tous signés avec la somme SHA1 de leur contenu. Une somme SHA1 occupe exactement 20 octets, soit 40 caractères hexadécimaux. Mais partout où cette somme est attendue, Git n'attend au miminum que trois de ces caractères. Tant qu'il n'y a pas d'ambiguïté avec d'autres objets débutant par les mêmes chiffres, il doit accepter de les résoudre. En pratique, les références courtes font généralement sept ou huit caractères.

Citation:

La ligne de commandes de git ne répondait plus alors je l'ai réinstallée. Ce faisant j'ai consacré deux à trois heures à choisir un éditeur, j'ai choisi VSCodium, que j'ai installé spécialement pour ça, et après ça quand je fais un commit, si j'oublie le paramètre -m, on m'affiche le fichier de message avec vim. Et là je suis d'accord avec la présentation qui en est faite, en résumé "à fuir". Et le fait est que j'ai mis un sacré bout de temps à savoir sortir de ce truc.

Ah, moi par contre, je ne travaille plus qu'avec VIM. :-) Mais trouver comment en sortir est effectivement un bizutage pour tous ceux qui l'essaient la première fois. Je te rassure, ce n'est pas plus facile avec Emacs…

Pièce jointe 637811

Citation:

Envoyé par Gluups

Joli !
Après il a encore fallu dire à Visual Studio de recharger tous les projets (pour être sûr mais il n'y en a qu'un), et ensuite ça s'exécute.

Oui, mais on n'a fait que se déplacer le long de la branche. Si tu veux abandonner les derniers commits en date pour que celui redevienne le sommet de la branche, continue ta lecture ici…

Citation:

Est-ce que c'est différent si dans l'historique sous Visual Studio je fais un clic droit sur ce commit et que je clique sur Rétablir ?

Je l'ignore mais c'est probable.
Citation:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 git checkout 6053b253a801c95672f216b0a85ac1ddda14aaab Warning: you are leaving 1 commit behind, not connected to any of your branches: 05d5c2d Revert "Revert "Revert "aucun changement non indexé""" If you want to keep it by creating a new branch, this may be a good time to do so with: git branch <new-branch-name> 05d5c2d HEAD is now at 6053b25 Mise à jour globale
C'est ce qu'on explique au-dessus. Tu es actuellement en exploration au milieu de ta branche, mais la référence master en pointe toujours le sommet et, donc, ce que tu créerais éventuellement ici n'aurait pas de nom et ne pourrait pas être retrouvé a posteriori. D'où l'incitation débutant par « If you want to keep it… »
Citation:
Envoyé par Gluups
Alors j'ai fait quelques modifs, y compris l'intégration du projet à la solution.

J'avais ça :
Code:

1 2 3 git branch -v * Inclusionduprojet 04b26e1 Voilà master a691acc [ahead 2, behind 6] test
Et après, j'ai voulu mettre ça dans le master. Ça coince un peu.
Code:

1 2 git merge Inclusionduprojet --into master Already up to date.
Ensuite il faut que je potasse le topo sur l'utilisation de Git dans Visual Studio, parce que là où je crois dire qu'il faut garder Form1 de Inclusionduprojet, Git comprend qu'il faut supprimer purement et simplement Form1 sans se poser aucune question. .

Euh ... Ce n'est pas tout-à-fait ce que j'ai voulu dire.
En principe, ce n'est pas du ressort de Git, sauf si tu as utilisé git rm ou un équivalent depuis VSCode.

Quoi qu'il en soit, la commande dédiée pour supprimer le haut d'une branche et la ramener à une position donnée est git reset. Mais on en parlera au prochain post parce que, là encore, il y a des subtilités à connaître.

26/04/2023, 10h58
Gluups

Ah, je vois que cette fois j'ai de la lecture, merci.
Apparemment, pour assimiler la notion de rebase et quelques autres il vaut mieux que je prenne mon temps.

J'ai pu débloquer la situation, ce qui reste un peu délicat c'est quand il y a des conflits à résoudre. Quelquefois il y a une interface pour ça dans Visual Studio, quelquefois pas.

Je pense une chose, si je crée une branche pour une fonctionnalité, et que pendant ce temps-là le master ne change pas ... Après le commit, le plus simple serait encore de renommer master en main, et newbranch en master, non ? Comme ça, pas de conflit à gérer.

Pour ce qui est de VSCode j'ai trouvé le point d’achoppement. VSCode installe dans la variable Path le chemin "C:\Program Files\VSCode\bin", alors que le programme, lui, est un niveau au-dessus. Alors j'ai ajouté un deuxième chemin, et maintenant j'ai bien VSCode pour éditer les fichiers.
Et là j'ai les infos dans le menu fichier : pour enregistrer Ctrl S, pour quitter Alt F4. En cherchant un peu plus, peut-être que je trouverai comment faire les deux d'une traite.

Si j'avais fait moins de zèle, aussi, j'aurais utilisé Notepad2, et ça aurait été immédiat. Mais la barre d'outils est petite, aussi.
26/04/2023, 17h11
Obsidian

Citation:

Envoyé par Gluups

J'ai pu débloquer la situation, ce qui reste un peu délicat c'est quand il y a des conflits à résoudre. Quelquefois il y a une interface pour ça dans Visual Studio, quelquefois pas.

C'est effectivement une raison pour apprendre directement l'outil. L'avantage est que quand on le maîtrise, non seulement on est à l'aise partout, mais on n'a pas besoin de « rétro-formation » pour utiliser les raccourcis proposés par Visual Studio, et on peut alors commencer à être vraiment efficace.

Citation:

Je pense une chose, si je crée une branche pour une fonctionnalité, et que pendant ce temps-là le master ne change pas ... Après le commit, le plus simple serait encore de renommer master en main, et newbranch en master, non ? Comme ça, pas de conflit à gérer.

Oui mais si ta branche master est paramétrée pour suivre une branche distante, il faut alors la « déparamétrer » puis reconfigurer la nouvelle branche pour qu'elle suive la branche master distante, tout cela sans que le serveur distant n'en sache rien. Donc c'est une fausse bonne idée.

Le mieux reste encore soit de rester sur la branche master quitte à revenir en arrière si c'est nécessaire, soit d'utiliser une branche comme tu le fais quand on n'a pas envie de perturber le flux principal et de la fusionner proprement à terme.

Citation:

Pour ce qui est de VSCode j'ai trouvé le point d’achoppement. VSCode installe dans la variable Path le chemin "C:\Program Files\VSCode\bin", alors que le programme, lui, est un niveau au-dessus. Alors j'ai ajouté un deuxième chemin, et maintenant j'ai bien VSCode pour éditer les fichiers.
Et là j'ai les infos dans le menu fichier : pour enregistrer Ctrl S, pour quitter Alt F4. En cherchant un peu plus, peut-être que je trouverai comment faire les deux d'une traite.

Pour les raccourcis clavier, ça concerne effectivement VSCode. Pour le reste, jette un œil à .git/config à la racine de ton dépôt, ainsi qu'au manuel de la commande git config : https://git-scm.com/docs/git-config . Bon, la page de manuel n'est pas la plus claire mais elle est exhaustive. Saute directement à la section « exemples » en bas de page si c'est trop confus.

Peux-tu nous refaire un git status et un git branch -vva pour que l'on voie où tu en es actuellement et que l'on puisse remettre ton dépôt au propre ?
26/04/2023, 22h02
Gluups

Avant de faire tout ça il va falloir une vraie nuit de sommeil.
Il y a une partie qui appelle des réponses plus ou moins évidentes, et une partie qui nécessite de gamberger ... plus qu'un peu.

Citation:

Envoyé par Obsidian

Ça dépend tout de même de ce que tu appelles « rebaser » (et à mon avis, tous tes ennuis viennent de là au départ) : « rebaser » signifie « débrancher et une branche et aller la rebrancher à partir d'une autre position ». Et pour ce faire, Git « rejoue » tous les commits de ta branche à partir du nouveau point de départ comme si tu les y avais saisis toi-même. Et une fois que c'est fait, Git déplace le nom de la branche pour le placer au sommet de la nouvelle.

Je crois qu'il va falloir que je relise plusieurs fois ce topo sur pull/push/rebase/checkout.

Et que je perde l'habitude d'arriver sur un projet qui fonctionne impec, faire un commit dessus, et ne plus réussir à le faire fonctionner.

Parce que ça m'est arrivé de nouveau sur un autre projet, et je crois que ça a suivi le même trajet : commit, intégration, et ensuite, sans que je comprenne pourquoi, je vois apparaître dans Visual Studio trois ou quatre modifications par rapport à ce commit, et en les rejouant avec Git il s'avère qu'il s'agit de la disparition du projet dans la solution.

Comme si j'avais sélectionné le projet dans l'explorateur de solutions, et que j'avais appuyé sur la touche suppression comme un bourrin. Sauf que là j'aurais été prévenu, et qu'on m'aurait demandé confirmation.

Alors que maintenant on me dit qu'on ne peut pas remettre le projet parce qu'il y a une modification plus récente. Envie de donner une baffe à ce môme et de lui dire arrête de tout casser. Ça rime à quoi, une solution sans projet dedans ?

Mais je suppose que si je m'embarque là-dedans maintenant on va perdre en clarté.

Alors je reviens au projet du début, où j'ai ajouté une fonctionnalité dans une autre branche.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 C:\Projets Visual Studio\WinForms\ListIrfanView>git branch Inclusionduprojet * master test C:\Projets Visual Studio\WinForms\ListIrfanView>git branch boutonlistefen C:\Projets Visual Studio\WinForms\ListIrfanView>git branch Inclusionduprojet * boutonlistefen master test C:\Projets Visual Studio\WinForms\ListIrfanView>git log --oneline cda8374 (HEAD -> boutonlistefen, origin/master, master) Validation des changements après intégration du projet 9fda548 Après validation : activation du projet adb84ff Après validation : activation du projet e4c9101 Revert "Revert "aucun changement non indexé"" 6d529c5 Mais qu'est-ce qu'il y a encore ? 68b3952 - 2 sortants faa6f3b Restaurer au 2 février f760bf5 Revert "Mise à jour globale"
Ah, j'allais oublier :
Code:

1 2 3 4 5 6 7 C:\Projets Visual Studio\WinForms\ListIrfanView>git branch -vva Inclusionduprojet 0b9480c [origin/Inclusionduprojet: ahead 7] Validation des changements après intégration du projet * boutonlistefen cda8374 Validation des changements après intégration du projet master cda8374 [origin/master] Validation des changements après intégration du projet test 81a49e9 Après validation : activation du projet remotes/origin/Inclusionduprojet 04b26e1 Voilà remotes/origin/master cda8374 Validation des changements après intégration du projet

27/04/2023, 10h52
Gluups

Citation:

Envoyé par Obsidian

C'est effectivement une raison pour apprendre directement l'outil. L'avantage est que quand on le maîtrise, non seulement on est à l'aise partout, mais on n'a pas besoin de « rétro-formation » pour utiliser les raccourcis proposés par Visual Studio, et on peut alors commencer à être vraiment efficace.

Bon alors pour la résolution des conflits ...
Il m'a semblé lire dans l'aide de Git que ça peut se faire à l'aide de l'éditeur, mais jusque là tout ce que j'ai vu l'éditeur me proposer c'est un fichier avec le message de commit, et tout un laïus en dessous avec # au début de chaque ligne.

Il n'y a que dans Visual Studio que j'ai parfois vu deux colonnes, une pour chaque version, et une case à cocher devant chaque bloc pour dire quelle version de chaque je veux conserver.
28/04/2023, 03h48
Obsidian
Citation:

Envoyé par Gluups

Je crois qu'il va falloir que je relise plusieurs fois ce topo sur pull/push/rebase/checkout.

En réalité, on aurait dû commencer par là mais as-tu déjà utilisé un autre logiciel de versioning avant Git (CVS, SVN, Mercurial…) et es-tu d'habitude relativement « à l'aise » avec, avant d'avoir eu ces ennuis, ou découvres-tu totalement le produit ? Toutes les réponses ici sont valables, ça va simplement orienter l'approche à suivre.

Quoi qu'il en soit :
- pull : tire à soi les éléments d'une branche que l'on ne possède pas encore en local et les intègre à cette branche (façon normale de travailler avec des collaborateurs).
- push : opération inverse. Intègre à la branche distante les éléments qui nous sont propres pour le moment ;
- checkout : Sert à « examiner » une révision donnée (donc un commit), où qu'elle soit dans l'historique. Git se « place alors dessus » (en y positionnant HEAD) et développe le contenu des fichiers de la révision concernée dans le répertoire de travail ;
- revert : Sert à produire un commit en annulant un autre, en produisant le changeset exactement inverse (comme sur Wikipédia) ;
- reset : Sert à ramener une branche à une position donnée de l'historique, en abandonnant ainsi tous ceux qui suivent. « coupe » le haut de la branche donc, et permet d'annuler les derniers commits en date. À utiliser quand on a commité par erreur ou que l'on change d'avis mais attention : cela réécrit l'histoire. Donc à faire avant de pousser en ligne.
- rebase : sert à rebaser une branche, c'est-à-dire la faire repartir d'un autre point de départ dans l'historique, tout en conservant son contenu.
Citation:

Et que je perde l'habitude d'arriver sur un projet qui fonctionne impec, faire un commit dessus, et ne plus réussir à le faire fonctionner.

En fait, l'une des grandes forces de Git est que, justement, tout est réparable et il est difficile de perdre définitivement des données avec. C'est quand même possible dans deux ou trois rares situations, mais il se trouve que c'est justement vers elles que se précipitent la plupart des débutants, donc il faut faire attention.

Mais hormis ces cas, Git est justement fait pour faciliter la collaboration et le développement participatif, puisqu'il est conçu à la base pour la gestion du développement du noyau Linux. Donc, en temps normal, c'est plutôt une bonne chose de récupérer un projet existant et essayer de faire ses armes dessus.

Citation:

Parce que ça m'est arrivé de nouveau sur un autre projet, et je crois que ça a suivi le même trajet : commit, intégration, et ensuite, sans que je comprenne pourquoi, je vois apparaître dans Visual Studio trois ou quatre modifications par rapport à ce commit, et en les rejouant avec Git il s'avère qu'il s'agit de la disparition du projet dans la solution.

Comme si j'avais sélectionné le projet dans l'explorateur de solutions, et que j'avais appuyé sur la touche suppression comme un bourrin. Sauf que là j'aurais été prévenu, et qu'on m'aurait demandé confirmation.

Oui, alors ça c'est un glossaire propre à Visual Studio et pour cela, il faudrait que l'on voie comment l'IDE versionne lui-même ses fichiers de configuration pour savoir s'il y réellement eu un impact.

Citation:

Alors que maintenant on me dit qu'on ne peut pas remettre le projet parce qu'il y a une modification plus récente. Envie de donner une baffe à ce môme et de lui dire arrête de tout casser. Ça rime à quoi, une solution sans projet dedans ?

Si ça fonctionne comme je le pense, c'est que c'est un effet de bord que tu risques de retrouver même si tu n'utilises pas VS : si tu demandes à Git de revenir à une révision antérieure, il va bien vouloir si tous les fichiers sont déjà enregistrés mais s'il y a eu des modifications entretemps dans ton dépôt, il va te demander avec raison : « fais-en quelque chose d'abord, car je vais les écraser et tu risques de les perdre ».

Citation:

Alors je reviens au projet du début, où j'ai ajouté une fonctionnalité dans une autre branche.

Ok. Tu te trouves donc sur master et tu crées une nouvelle branche boutonlistefen qui, par défaut et en l'absence d'indications explicites, est déclarée à la position courante. Donc la même que master dans notre exemple. Au fur et à mesure que tu enregistreras des commits sur l'une ou sur l'autre, elles vont diverger, jusqu'à ce que tu décides de refusionner cette branche au sein de master.

Citation:

Envoyé par Gluups

Bon alors pour la résolution des conflits ...
Il m'a semblé lire dans l'aide de Git que ça peut se faire à l'aide de l'éditeur, mais jusque là tout ce que j'ai vu l'éditeur me proposer c'est un fichier avec le message de commit, et tout un laïus en dessous avec # au début de chaque ligne.

Il n'y a que dans Visual Studio que j'ai parfois vu deux colonnes, une pour chaque version, et une case à cocher devant chaque bloc pour dire quelle version de chaque je veux conserver.

Tout-à-fait. Le message de l'éditeur est bien celui du commit à enregistrer… dès lors que tu as résolu les conflits. le « # » est le symbole de commentaire dans la majorité des fichiers de scripts. Dans le cas d'un commit, ça permet à Git de t'indiquer tout un tas d'informations qui ne seront PAS reprises dans le message final, mais que tu peux éventuellement extraire si tu en as besoin.

Pour la résolution des conflits, en effet, il y a beaucoup d'outils qui permettent de faire un choix « gauche ou droite » pour savoir laquelle des deux parties en conflits on souhaite conserver mais lorsque l'on utilise Git sans IDE, la manière de procéder consiste pour lui à directement encadrer les parties concernées dans le fichier lui-même, sous cette forme :
Code:

1 2 3 4 5 6 7 8 9 <<<<<<< contenu local ========== contenu distant >>>>>>
C'est purement du texte. Il suffit d'ouvrir son fichier source normalement comme si on le faisait pour travailler dessus et de nettoyer ces sections pour n'en conserver que ce qui nous intéresse. Ensuite, on indique à Git que l'on a fini de résoudre les conflits et on enregistre le tout comme un commit ordinaire.
28/04/2023, 11h14
Gluups

Citation:

Envoyé par Obsidian

git pull, à présent, n'a rien à voir. Cette commande, symétrique de git push, sert simplement à importer dans sa branche courante les dernières modifications en date sur la branche homologue qu'elle suit (généralement, c'est master en local qui suit origin/master sur le serveur distant). C'est ce que l'on utilise normalement pour intégrer à sa branche de travail soit les modifications de ses collègues, soit ses propres modifications lorsqu'elles ont eu lieu sur une autre machine. Lorsque les modifications n'ont eu lieu que d'un seul côté, c'est facile : soit c'est du nôtre et il n'y a rien à faire de plus, soit c'est du côté serveur et dans ce cas, on peut les appliquer directement à la suite de l'état courant de la branche locale. Git appelle cela le fast-forward (avance rapide) car il n'y a pas besoin de procéder à une opération de fusion (sauf si on lui demande explicitement de le faire quand même).

Je ne m'étais pas trompé en disant qu'il fallait que je prenne mon temps pour lire, parce que je m'apprêtais à utiliser push pour mettre à jour master avec le contenu de boutonlistefen, or ... ça n'a rien à voir.
28/04/2023, 12h33
Gluups
J'aimerais bien aller plus vite, mais ce que j'ai fait avec les citations illustre ce qui peut se passer avec des nuits trop courtes. J'ai loupé que si on coupe une liste pour citer un message en plusieurs fois, il faut remettre la balise LIST à chaque fois.

Par ailleurs je ne sais pas si la mise en forme du site a changé cette nuit ou si c'est ma vue qui a baissé, mais j'ai passé tellement de temps à me bagarrer avec un texte écrit avec une police trop petite sur trois fois la largeur de l'écran, que je n'avais pas vu que j'avais un nouveau message.

J'ai utilisé plus ou moins tous les outils de contrôle de version, sans forcément approfondir autant qu'il aurait fallu.
Pour autant, c'était la première fois, cette semaine, que je perdais un projet et ne pouvais plus l'exécuter.
Citation:
Envoyé par Obsidian

En réalité, on aurait dû commencer par là mais as-tu déjà utilisé un autre logiciel de versioning avant Git (CVS, SVN, Mercurial…) et es-tu d'habitude relativement « à l'aise » avec, avant d'avoir eu ces ennuis, ou découvres-tu totalement le produit ? Toutes les réponses ici sont valables, ça va simplement orienter l'approche à suivre.

Quoi qu'il en soit :
pull : tire à soi les éléments d'une branche que l'on ne possède pas encore en local et les intègre à cette branche (façon normale de travailler avec des collaborateurs).
Alors tirer à soi, d'accord, mais comme je précise ailleurs, il s'agit que je fasse attention de ne pas comprendre de travers.
Citation:
push : opération inverse. Intègre à la branche distante les éléments qui nous sont propres pour le moment ;
checkout : Sert à « examiner » une révision donnée (donc un commit), où qu'elle soit dans l'historique. Git se « place alors dessus » (en y positionnant HEAD)/ et développe le contenu des fichiers de la révision concerndans le répertoire de travail ;
Et donc, ça permet de coder à partir de ce commit, tout en le conservant dans l'historique.
Citation:
revert : Sert à produire un commit en annulant un autre, en produisant le changeset exactement inverse (comme sur Wikipédia) ;
Ah, oui, je crois qu'il va falloir que je fasse un essai ou deux.
Citation:
reset : Sert à ramener une branche à une position donnée de l'historique, en abandonnant ainsi tous ceux qui suivent. « coupe » le haut de la branche donc, et permet d'annuler les derniers commits en date. À utiliser quand on a commité par erreur ou que l'on change d'avis mais attention : cela rééc[rit l'histoire. Donc à faire avant de pousser en ligne.
Ça réécrit tellement l'histoire que je ne comprends pas du premier coup. J'essaierai en relisant.
Citation:
rebase : sert à rebaser une branche, c'est-à-dire la faire repartir d'un autre point de départ dans l'historique, tout en conservant son contenu.
Et à ce que je me rappelle, ça mérite de prendre le temps de bien le comprendre, ça aussi.

Citation:

En fait, l'une des grandes forces de Git est que, justement, tout est réparable et il est difficile de perdre définitivement des données avec.

Tant mieux.

Citation:

C'est quand même possible dans deux ou trois rares situations, mais il se trouve que c'est justement vers elles que se précipitent la plupart des débutants, donc il faut faire attention.

Si la plupart des débutants se précipitent vers deux ou trois situations, ça m'étonne qu'elles soient rares.

Citation:

Mais hormis ces cas, Git est justement fait pour faciliter la collaboration et le développement participatif, puisqu'il est conçu à la base pour la gestion du développement du noyau Linux. Donc, en temps normal, c'est plutôt une bonne chose de récupérer un projet existant et essayer de faire ses armes dessus.

Il n'empêche que pour le projet que j'ai voulu commiter hier, j'ai l'impression que c'est une bonne chose que j'aie une sauvegarde du disque.
Je ne vais pas entrer dans les détails tout de suite, car si je commence à donner des extraits de log pour deux projets, on va vite se mélanger les pinceaux.
Citation:
[Intégration d'un projet à une solution]
Oui, alors ça c'est un glossaire propre à Visual Studio et pour cela, il faudrait que l'on voie comment l'IDE versionne lui-même ses fichiers de configuration pour savoir s'il y réellement eu un impact.

Si ça fonctionne comme je le pense, c'est que c'est un effet de bord que tu risques de retrouver même si tu n'utilises pas VS : si tu demandes à Git de revenir à une révision antérieure, il va bien vouloir si tous les fichiers sont déjà enregistrés mais s'il y a eu des modifications entretemps dans ton dépôt, il va te demander avec raison : « fais-en quelque chose d'abord, car je vais les écraser et tu risques de les perdre ».
Pour la résolution des conflits, en effet, il y a beaucoup d'outils qui permettent de faire un choix « gauche ou droite » pour savoir laquelle des deux parties en conflits on souhaite conserver mais lorsque l'on utilise Git sans IDE, la manière de procéder consiste pour lui à directement encadrer les parties concernées dans le fichier lui-même, sous cette forme :

Code:

1 2 3 4 5 6 7 8 9 <<<<<<< contenu local ========== contenu distant >>>>>>

C'est purement du texte. Il suffit d'ouvrir son fichier source normalement comme si on le faisait pour travailler dessus et de nettoyer ces sections pour n'en conserver que ce qui nous intéresse. Ensuite, on indique à Git que l'on a fini de résoudre les conflits et on enregistre le tout comme un commit ordinaire.
Ah oui ben j'ai eu ça trois ou quatre fois à me taper dans Visual Studio, et là je trouve que ce n'est pas du boulot terminé. Ouvrir le projet et en voulant exécuter voir "175 erreurs", à corriger, ça augure de s'engager dans une belle séance à ramasser les morceaux.

Surtout quand il s'agit de choisir une des deux versions, sans vraiment s'intéresser à ce qu'il y a dans l'autre.

Alors que d'autres fois j'ai vu qu'il suffisait de trois clics pour faire ça.
28/04/2023, 16h04
Gluups

Citation:

Envoyé par Gluups

[Fichier avec des morceaux de deux versions]

Ah oui ben j'ai eu ça trois ou quatre fois à me taper dans Visual Studio, et là je trouve que ce n'est pas du boulot terminé. Ouvrir le projet et en voulant exécuter voir "175 erreurs", à corriger, ça augure de s'engager dans une belle séance à ramasser les morceaux.

Surtout quand il s'agit de choisir une des deux versions, sans vraiment s'intéresser à ce qu'il y a dans l'autre.

Alors que d'autres fois j'ai vu qu'il suffisait de trois clics pour faire ça.

Je relis ça après une petite sieste, et ça commence à s'éclairer.

Il va falloir que je trace avec beaucoup plus de précision ce qui se passe quand je restaure une ancienne version, par checkout à ce que je me rappelle, car j'ai tendance à avoir des fichiers manquants.

Logiquement, après un checkout, si c'est sur un commit qui était opérationnel, je m'attends à trouver un projet opérationnel.
Donc si Visual Studio me dit qu'il y a trois modifications, ou Git que certains fichiers ne sont pas intégrés au contrôle de version, il faut que je commence par savoir d'où ça vient. Quand c'est un fichier de config il se peut que ça soit normal, quand c'est Form1.cs donc le fichier par où on commence à taper du code, il y a un loup.

Autrement à force de faire des pull et des push dans tous les sens je finis par avoir un fichier, mais pas forcément un projet complet dans une version cohérente. Et du coup, ça risque de donner des effets de bord pas conformes à ce que prévoit la doc.
01/05/2023, 01h39
Obsidian
Citation:

Envoyé par Gluups

J'ai utilisé plus ou moins tous les outils de contrôle de version, sans forcément approfondir autant qu'il aurait fallu.
Pour autant, c'était la première fois, cette semaine, que je perdais un projet et ne pouvais plus l'exécuter.

Dans ce cas, je te conseille tout de suite « Learn Git Branching » qui propose des exercices amusants en ligne pour se faire la main et qui, en outre, a le bon goût de représenter le graphe de l'historique de façon interactive, ce qui nous manque ici. Pas qu'on ne le fasse pas du tout, mais en dessiner un dans la boîte des commentaires devient vite fastidieux sans outil dédié.

Par ailleurs, si tu as déjà utilisé CVS ou Mercurial, qui eux sauvent à chaque fois le différentiel appliqué à chaque fichier (dans des fichier « *,v » pour RCS et CVS), Git est un système à snapshots. Ça veut dire que d'une part, chaque fois que tu vas modifier un fichier, ne serait-ce que d'un seul octet, il va le ré-enregistrer entièrement (ce qui ne pose globalement pas de problème, on verra plus loin pourquoi) mais également qu'il utilise un système d'objets immuables, chaque objet étant un fichier compressé et portant comme nom la somme SHA1 de son contenu. C'est ce qui fait qu'un objet est immuable, car on ne peut pas en modifier le contenu sans modifier sa somme. Lorsqu'on le fait quand même, Git le remplace en fait par un autre objet, reconstruit depuis zéro mais à partir des données du précédent.

Il y a exactement quatre types d'objets : les blob, les tree, les commits et les tags annotés (les tags ordinaires, eux, sont de simples étiquettes gérés de la même façon que les branches). Si on laisse les tags annotés de côté pour le moment (qui n'ont pas d'intérêt pour le sujet qui nous intéresse présentement) :
- Les blobs contiennent une séquence de données arbitraire (généralement le contenu d'un fichier) ;
- Les tree sont des arborescences : c'est à chaque fois une liste de noms de fichiers + chemin d'accès, chaque entrée étant associé à un blob (le contenu du fichier) ;
- Les commits sont un petit fichier texte qui contient toutes les informations nécessaires à décrire la révision concernée, c'est-à-dire la date, l'auteur, un certain nombre de headers supplémentaires, le message saisi dans l'éditeur, et :
  — l'identifiant d'un objet tree qui référence tous les fichiers de la révision concernée et qui correspond en fait à l'état de l'index au moment du commit ;
  — l'identifiant de l'objet du commit parent, c'est-à-dire celui sur lequel on se trouvait au moment où l'on a produit celui-ci.
Sur ce dernier point, la grande majorité des commits ont donc un et un seul champ « parent », mais ils peuvent en fait en avoir un nombre arbitraire : soit zéro dans le cas du commit initial (normalement un seul par dépôt, sauf si on fait exprès de créer un commit orphelin, chose dont on ne parlera pas ici), soit un seul dans les cas normaux, soit au minimum deux si on a fusionné deux branches (donc deux la plupart du temps, mais dans l'absolu, on peut fusionner n branches en même temps. On n'en parlera pas non plus).

Tu peux examiner un des tiens avec git cat-file -p cda8374, par exemple.

Ce qui est important de saisir ici : chaque commit référençant directement le précédent, ils constituent ainsi une sorte de longue chaîne qui est en fait le fameux graphe dont on parle depuis le départ. Cela veut dire que c'est bien l'ensemble des révisions qui forment l'historique, de fait. Une branche est une lignée de commits dans l'historique. Ce n'est pas un container ou un objet particulier comme cela peut être implémenté sous d'autres logiciels de versioning.

Et en conséquence, les « branches » sous Git telles que tu les vois avec git branch ne sont en fait qu'une référence vers le commit se trouvant actuellement au sommet de ces branches. C'est donc un point de départ depuis lequel il suffit ensuite de tirer le fil. Tu peux vérifier dans .git/refs/heads : tu y trouveras des fichiers qui portent exactement le nom de tes branches, fichiers qui contiennent exactement quarante caractères plus un retour à la ligne. Si tu affiches leur contenu, tu verras que c'est bien l'identifiant SHA1 du commit du sommet de la branche.

Il faut enfin évoquer le garbage collector (ou « ramasse-miettes ») : lorsque certains objets deviennent obsolètes (suppression de branche ou troncature, amendement, rebasage reconstruisant la branche…), ils ne sont pas supprimés immédiatement. Ils ne le seront que périodiquement, chaque fois que Git estimera nécessaire de lancer le garbage collector. Il fait cette estimation chaque fois que tu lances une commande et, le cas échéant, lance un processus en arrière-plan si c'est judicieux de le faire, qui continuera à fonctionner même après que la commande principale a rendu la main.

→ Ce garbage collector supprimera alors les objets uniquement si 1) l'objet concerné n'est plus référencé par rien (ni commit enfant, ni tag, ni branche, ni entrée de reflog) et 2) s'il est plus ancien qu'un certain âge (typiquement 3 mois par défaut).

C'est techniquement une très bonne approche car un tel ramassage est coûteux en ressources (long, beaucoup d'accès disques…) et que de l'autre côté, cela ne concerne à chaque fois que très peu d'objets par rapport au dépôt entier et, donc, l'espace qu'ils occupent n'est pas pénalisant. Cela signifie également que si tu détruis par accident quelque chose que tu as commité au moins une fois, tu es quasiment certain de pouvoir le récupérer d'une manière ou d'une autre. Il suffit de retrouver les identifiants des objets concernés, et il existe plusieurs outils pour cela, le principal étant le reflog.

Citation:

Alors tirer à soi, d'accord, mais comme je précise ailleurs, il s'agit que je fasse attention de ne pas comprendre de travers.

Imaginons que toi et ton équipe soyez synchrones sur votre projet, puis que tu partes en vacances une semaine. À ton retour, la branche côté serveur aura pris de l'avance sur la tienne.
```
   Toi               Serveur

                  origin/master
                        ↑
                        O Commit 6
                        |
                        O Commit 5
                        |
  master                O Commit 4
    ↑                   |
    O Commit 3          O Commit 3
    |                   |
    O Commit 2          O Commit 2
    |                   |
    O Commit 1          O Commit 1
```
Dans cette situation, il suffit de récupérer les commits 4, 5 et 6 et les appliquer sur ta branche pour que les deux soient de nouveau synchrones. C'est ce qui se passe avec les plupart des DVCS et avec Git en particulier, si on a bien saisi ce qui est exposé au paragraphe précédent, on comprend qu'il suffit même de récupérer les objets et de mettre à jour l'étiquette « master » en lui affectant l'identifiant du commit 6 pour que notre branche master locale soit de nouveau à jour. C'est ce que Git appelle « l'avance rapide » (fast-forward).

Si c'est ton équipe qui part en vacances et toi qui travaille, le cas est le même mais dans l'autre sens : il faut pousser tes modifications sur le serveur, mais l'opération sera la même.

Si en revanche, vous êtes tous au travail en même temps et que vous êtes synchrones au commit 3, comme dans l'exemple ci-dessus, il est probable que vous déposiez chacun votre propre commit au même niveau :
```
   Toi               Serveur

  master          origin/master
    ↑                   ↑
    O Commit 5          O Commit 4
    |                   |
    O Commit 3          O Commit 3
    |                   |
    O Commit 2          O Commit 2
    |                   |
    O Commit 1          O Commit 1
```
Ici, vos branches ont divergé puisqu'elles sont parties chacune dans une direction propre. Il faut donc les fusionner avec git merge (appelé automatiquement si tu fais git pull). À l'issue de la résolution des éventuels conflits, tu vas te retrouver avec ceci :
```
             ↑
             O Commit 6 (fusion des deux branches)
             |
         +---+---+
         |       |
Commit 5 O       O Commit 4
         |       |
         +---+---+
             |
             O Commit 3
             |
             O Commit 2
             |
             O Commit 1
```
Il est important de remarquer ici que, dans cette situation, Git ne peut pas se contenter d'intégrer les commit 4 et 5 « directement dans l'ordre chronologique » en insérant, sur ta branche, le commit 4 entre le 3 et le 5 sur ta branche, comme s'il s'agissait d'une simple régularisation car ces commits, l'un comme l'autre, référencent directement le commit 3 comme étant leur père. Il est possible de le faire a posteriori mais cela implique de ré-écrire l'histoire récente (cela peut se faire notamment lors d'un rebasage) et de choisir lequel doit prendre place avant l'autre.

Cela se fait, mais pour ainsi dire jamais en production sur le serveur commun. À la place, soit on fait des « pull requests », c'est-à-dire que chaque développeur prépare une branche candidate à l'intégration puis, quand elle est prête, le mainteneur choisit de la fusionner à la branche principale (c'est ce qui se fait avec le noyau Linux, notamment), soit c'est le développeur qui résout lui-même le tout de son côté, place ses propres commits au sommet de la partie commune de la branche, prévient si possible les autres développeurs pour qu'ils suspendent leur activité un instant (le temps de l'opération) et pousse le tout une fois qu'il est certain qu'il n'y aura pas de conflit sur le serveur. À charge ensuite aux autres développeurs de faire un pull de leur côté et de faire exactement le même travail, s'il s'avère nécessaire.

Citation:

[ checkout ] … Et donc, ça permet de coder à partir de ce commit, tout en le conservant dans l'historique.

Oui, mais pas tout-à-fait : git checkout sert avant tout à rappeler une révision donnée dans l'historique, et heureusement qu'on le peut sinon cela n'aurait aucun intérêt de les enregistrer. Tout comme push et pull, c'est une commande qui existe depuis les tous premiers VCS.

Lorsque tu appelles checkout, Git va se « placer dessus » (en y positionnant « HEAD ») et va développer dans le répertoire de travail les fichiers qui y correspondent. Tu retrouves donc ton projet dans l'état dans lequel il était au moment où tu avais effectué le commit, mais attention :
```
  master
    ↑
    O Commit 5
    |
    O Commit 4
    |
    O Commit 3 ← « vous êtes ici »
    |
    O Commit 2 
    |
    O Commit 1
```
D'abord, même si tu t'es déplacé sur « commit 3 », le sommet de la branche master, lui, bien resté sur le « commit 5 ».

Ensuite, lorsque tu utilises checkout avec un nom de branche, Git considère que tu veux travailler avec et tu bascules dessus. Si tu lui passes autre chose (un identifiant SHA1, un tag, ou même un nom de branche mais accompagné de décorateurs comme ^ ou ~), tu passes en « état détaché », c'est-à-dire non lié à une branche. La différence est qu'en état attaché, l'étiquette de la branche est mise à jour lorsque tu commites pour qu'elle pointe toujours sur le dernier en date. Sinon, seul le commit est enregistré. Ça ne t'empêche pas d'en faire plusieurs d'affilée mais pour l'instant, ils ne seront référencés par rien et tu ne pourras pas les retrouver ensuite.
```
  master
    ↑
    O Commit 5
    |
    O Commit 4
    |
    |
    |  O Commit 8 ← On en est là.
    |  |
    |  O Commit 7
    |  |
    |  O Commit 6
    | /
    |/
    O Commit 3 
    |
    O Commit 2 
    |
    O Commit 1
```
Dans ce dernier cas, tu peux mettre un tag sur le dernier commit ou y créer une branche, non seulement pour pouvoir y revenir mais surtout pour s'assurer qu'ils ne seront pas emportés par le garbage collector. Mais en réalité, ce que l'on fait surtout, c'est se déplacer sur ce point, créer une nouvelle branche (à cet endroit, donc), basculer sur cette branche et entamer le développement. Il existe d'ailleurs des raccourcis pour le faire en une seule fois.

Par contre :
- Lors d'un checkout, le logiciel ne modifie QUE les fichiers qu'il suit. Il n'efface pas le working directory pour le remplir ensuite avec les fichiers de la révision sélectionnée, mais se contente de remplacer le contenu de ceux-ci. Cela signifie que si tu as des fichiers en plus de ceux qui sont officiellement suivis dans ton dépôt, ils resteront intouchés. Cela peut néanmoins avoir une incidence sur le fonctionnement d'un projet, surtout s'ils sont autogénérés !
- Ces fichiers restent intouchés mais il se peut que tu bascules d'une version ou ils n'existent pas encore vers une autre où ils ont été ajoutés. Cela peut se produire dans l'autre sens aussi s'ils ont été supprimés au cours de l'histoire. Dans ce cas, tu peux avoir du mal à changer de version tant que ces fichiers sont présents. Si tu les as recréés toi-même, il faudra les enregistrer quelque part…
- De la même façon, Git ne te laissera pas changer de révision s'il y a des changement effectués sur un ou plusieurs des fichiers suivis et qui ne soient pas encore enregistrés. Il te demandera de le faire d'abord.
Et surtout
- On est bien d'accord que git checkout ne fait que te déplacer dans l'historique, les branches restant à leur place. Si tu veux faire repartir la branche master de la révision que tu as appelée avec checkout, il va falloir faire d'autres opérations.
Citation:

[ reset ]Ça réécrit tellement l'histoire que je ne comprends pas du premier coup. J'essaierai en relisant.

En principe, tu dois déjà y voir plus clair à la lecture du laïus ci-dessus.

On comprend déjà qu'en se déplaçant avec checkout et en forçant la re-création d'une branche existante à cet endroit (ou en l'effaçant d'abord), on pourrait arriver à ses fins. Ça se fait, et ça va marcher sous Git, mais ce n'est pas propre et ce n'est pas la manière orthodoxe de faire (et ça pourrait poser des problèmes avec les DVCS qui fonctionnent différemment).

Si l'on peut dire que git reset est bien faite pour annuler les derniers commits en date d'une branche, retiens cependant qu'elle sert à « ramener une branche à une position donnée » (par défaut, la branche courante, sur laquelle on se trouve). Dans tous les cas, la branche proprement dite (c'est-à-dire l'étiquette qui pointe son sommet) sera bien ramenée à la révision que tu indiques, mais il existe trois manières de le faire, indiquées par une option :
- --soft : ne ramène que la branche à la position indiquée, laisse intact l'index et le working directory ;
- --mixed (option par défaut) : ramène la branche ET l'index à la position indiquée, laisse intact le working directory ;
- --hard : ramène de force la branche, l'index ET le working directory à la position indiquée. Écrase le contenu des fichiers qui s'y trouve si nécessaire.
On comprend alors que « reset --hard <version> » était probablement la commande qu'il t'aurait fallu dès le départ mais également pourquoi on ne l'évoque qu'au 19ème commentaire : c'est précisément une des commandes dont on parlait, celles vers lesquelles les débutants se précipitent et qui peut leur faire perdre des données sans espoir de les récupérer, alors que Git est censé être un des systèmes les plus résilients de ce côté-là.

Citation:

[ rebase ]Et à ce que je me rappelle, ça mérite de prendre le temps de bien le comprendre, ça aussi.

Méfiance. C'est effectivement très pratique et très naturel quand on développe mais sauf (grosse) erreur de ma part, je crois que ça a justement été introduit avec Git. Cela a été porté ensuite au moins sur Mercurial et sous Bazaar, mais sous forme de plugins et la dernière fois que j'ai essayé sous Mercurial (fin 2011, ça commence à être vieux), cela avait corrompu mon dépôt.

C'est en revanche tout-à-fait sûr sous Git et c'est très simple d'usage, mais ce n'est pas forcément ce vers quoi il faut se lancer immédiatement. L'idée est de faire ceci :
```
          De :                                 Vers :

                                                 O Commit 10
                                                 |
                                                 O Commit 9
                                                 |
                                                 O Commit 8
                                                /
            ↑                                 ↑/
  Commit 7  O                       Commit 7  O
            |  O Commit 10                    |
  Commit 6  O  |                    Commit 6  O
            |  O Commit 9                     |
  Commit 5  O  |                    Commit 5  O
            |  O Commit 8                     |
  Commit 4  O /                     Commit 4  O
            |/                                |
  Commit 3  O                       Commit 3  O
            |                                 |
  Commit 2  O                       Commit 2  O
            |                                 |
  Commit 1  O                       Commit 1  O
```
L'opération consiste donc à partir du commit 10, à remonter l'historique pour se rendre compte que le point de jonction est juste avant le commit 8, en déduire que la branche en question est formée par les commits 8, 9 et 10, « rejouer » (càd : réappliquer leur changeset) ces commits dans l'ordre à partir du nouveau point de départ (ici le commit 7) et replacer le nom de branche au sommet du nouveau commit 10 s'il y en avait un et qu'il y a lieu de le faire.

« rebaser » une branche sert donc bien à « changer de base », c'est-à-dire la débrancher et la rebrancher autre part.

Ça a l'air élémentaire comme ça mais en réalité, c'est assez difficile à réaliser quand le modèle général n'est pas celui de Git et de fait, ce n'était pas utilisé à large échelle avant lui. Les gens se débrouillaient avec merge.

Attention toutefois : prudence si tu rebases une branche qui contient elle-même des points de fusion (merge). Voir ce fil : publication de la FAQ Git.

Citation:

Si la plupart des débutants se précipitent vers deux ou trois situations, ça m'étonne qu'elles soient rares.

Ça vaut le coup de s'y attarder un instant : un certain nombre de commandes sont dotées de l'option « -f », pour « --force », exactement comme l'est la commande rm sous Unix (remove : effacer un fichier). Cela permet de forcer l'action si c'est possible en dépit des mesures de sécurité.

Par exemple : git checkout ne te laissera pas changer de révision si des changements non enregistrés sont en cours, mais git checkout -f le fera quand même (et écrasera le contenu) ;

Autre exemple : git branch <nom de branche> ne créera pas la nouvelle branche si elle existe déjà (et heureusement). Par contre, git branch -f le fera quand même là aussi : l'ancien nom de branche sera effacé et le nouveau sera déclaré à la position courante. La commande t'indiquera quand même une dernière fois quelle était l'ancienne position avant de la remplacer. Tu as alors intérêt à bien la noter si ce n'était pas réellement ce que tu voulais faire.

Normalement, il n'y pas plus de raison d'utiliser « -f » sous Git qu'il n'y en a avec « rm ». Si on le fait, cela signifie « ok, je suis prévenu mais je sais ce que je fais ». Pourtant, reconnais que ces deux possibilités ont l'air très séduisantes présentées comme ça. Ajoute git reset --hard à cette liste, et on comprend qu'on puisse être tenté de forcer les commandes quand on se retrouve noyé sous des messages d'avertissements auxquels on ne comprend plus rien. C'est ainsi qu'une large proportion de débutants se précipitent d'emblée vers les rares commandes qu'il ne faut pas utiliser, du moins pas tout de suite.

Bref : dans le doute, commite tes changements et corrige ton historique ensuite car même si tu te perds, tu auras toujours deux semaines de délai de grâce si l'objet n'est plus référencé nulle part et trois mois s'il apparait dans un reflog. Tu pourras alors toujours retrouver tes petits, fût-ce avec l'aide d'une personne expérimentée. Si tu tapes d'emblée dans les commandes ci-dessus, tu risques de perdre les données non enregistrées.

Citation:

Il n'empêche que pour le projet que j'ai voulu commiter hier, j'ai l'impression que c'est une bonne chose que j'aie une sauvegarde du disque.
Je ne vais pas entrer dans les détails tout de suite, car si je commence à donner des extraits de log pour deux projets, on va vite se mélanger les pinceaux.

C'est toujours une bonne chose d'avoir une sauvegarde. Par contre, il ne faut pas finir comme lui : https://xkcd.com/1597/

Le principe général de Git reste très simple : des commits sous forme d'objets, qui forment eux-mêmes leur propre graphe et au sein duquel on peut se promener. Donc c'est aussi bien d'apprendre tout de suite à le réparer lorsque l'on est perdu.

Citation:

Ah oui ben j'ai eu ça trois ou quatre fois à me taper dans Visual Studio, et là je trouve que ce n'est pas du boulot terminé. Ouvrir le projet et en voulant exécuter voir "175 erreurs", à corriger, ça augure de s'engager dans une belle séance à ramasser les morceaux.

Et oui ! Ça arrive fréquemment, même en équipe, et c'était même pire avec les autres systèmes parce que là, il fallait vraiment faire le même dans l'historique des modifications apportées à un fichier. On ne pouvait pas se contenter de revenir à une position donnée, du moins pas facilement, et on ne pouvait pas non comparer aisément deux positions trop éloignées.

Reste à savoir ce qui a réellement provoqué ces « 175 erreurs ». Probablement pas du développement pur, parce que ça ferait beaucoup de matériel à produire d'abord.

Citation:

Alors que d'autres fois j'ai vu qu'il suffisait de trois clics pour faire ça.

C'est généralement possible en une seule commande sous Git aussi, à condition d'être certain de savoir ce que l'on veut faire.

Citation:

Envoyé par Gluups

Je relis ça après une petite sieste, et ça commence à s'éclairer.
Il va falloir que je trace avec beaucoup plus de précision ce qui se passe quand je restaure une ancienne version, par checkout à ce que je me rappelle, car j'ai tendance à avoir des fichiers manquants.

Appuie-toi surtout sur l'outil qui te représente ton historique de façon graphique. VSCode doit le faire, sinon il existe beaucoup d'outils pour cela. Moi j'utilise tig sous Linux car il fonctionne en mode texte dans un terminal.

Citation:

Logiquement, après un checkout, si c'est sur un commit qui était opérationnel, je m'attends à trouver un projet opérationnel.

Normalement oui, sauf s'il y a des fichiers parasites non suivis en plus.

Citation:

Donc si Visual Studio me dit qu'il y a trois modifications, ou Git que certains fichiers ne sont pas intégrés au contrôle de version, il faut que je commence par savoir d'où ça vient.

Absolument, et ça rejoint ce que l'on disait plus haut.

Citation:

Quand c'est un fichier de config il se peut que ça soit normal, quand c'est Form1.cs donc le fichier par où on commence à taper du code, il y a un loup.

Tout-à-fait, et c'est pour cela qu'en plus de git status, il faut également utiliser git diff pour voir ce qui est en suspens dans le working directory par rapport au commit qu'on est censé avoir ouvert, ainsi que git diff --cached pour voir ce que tu as déjà ajouté avec git add mais pas encore commité.

Citation:

Autrement à force de faire des pull et des push dans tous les sens je finis par avoir un fichier, mais pas forcément un projet complet dans une version cohérente. Et du coup, ça risque de donner des effets de bord pas conformes à ce que prévoit la doc.

Ne fais pas de « pull » et « push » intempestifs et encore moins « dans tous les sens » : n'oublie pas que ces commandes impliquent « merge ». Si fais « push » sans savoir ce que tu fais et que ton dépôt est en désordre, tu vas « intégrer » cette pagaille au serveur distant utilisé par les autres développeurs (s'il te laisse le faire).

Si tu veux travailler efficacement et que tu ne te sens pas encore d'attaque pour remettre ton dépôt actuel sur ses pieds (ce que l'on peut comprendre), je te conseille ce qui suit :
- Conserve le dépôt actuel et n'y touche plus (tu le remettras au propre ultérieurement et tu en auras besoin pour comprendre a posteriori ce que tu avais fait à ce moment) ;
- Clone à nouveau le projet qui t'importe avec git clone mais dans un autre répertoire ;
- Déplace-toi directement sur le commit qui t'intéresse avec git checkout si ce n'est pas le dernier en date ;
- Crée une branche qui t'est propre, appelons-la par exemple devlocal, avec git branch devlocal. Elle sera créé sur le commit courant (donc celui qui t'intéresse) ;
- Bascule vers cette branche avec git checkout devlocal. Tu ne vas pas changer de commit car la branche est au même endroit, mais Git saura que c'est sur elle que tu travailles désormais ;
- Fais tous tes changements depuis cette branche. Même si tu fais des bêtises avec, master restera au même endroit et les commits qu'elle contient resteront intouchés, même ceux qui sont en communs avec ta branche (c'est-à-dire tous ceux qui sont antérieurs au point où tu l'as créée) ;
- Tu peux éventuellement pousser ta branche sur le serveur si tu souhaites la sauvegarder et/ou la partager. Dans ce cas, il faudra créer une branche distante et la configurer pour qu'elles se suive mais en réalité, la première fois, git push depuis ta branche te renverra un message qui t'indiquera la commande exacte qu'il faut saisir ;
- Quand tu commenceras à être à l'aise, tu pourras éventuellement commencer à intégrer dans ta branche les dernières modifs en date sur master ;
- Quand tu seras totalement à l'aise et que ta tâche actuelle sera terminée, tu pourras fusionner ta branche avec master pour qu'elles n'en fasse plus qu'une et que ton travail soit officiellement intégré au tronc commun. Tu pourras alors en ouvrir une autre (ou même reprendre celle-ci) pour démarrer une nouvelle tâche.
Allez zou. Prochain épisode : git stash.

Bon courage.