Discussion :

[benkunz]

Bonjour,
j'utilise git sur mon Mac en local, donc sans compte GitHub.
j'ai un projet avec plusieurs commits.
mon but est d'être capable de remettre mon projet à un état antérieur pour faire un petit test vite fait puis de rebasculer sur la dernière version du code. J'ai donc pas envie d'enchainer les "Revert changes in commit" qui pourraient fonctionner mais qui vont vite rendre mon historique de commit illisible... Comment feriez vous ?
merci

[Obsidian]

Bonjour,
C'est exactement à ça que sert git checkout, qui est l'une des commandes fondamentales d'à peu près tous les logiciels de versioning

Tu peux utiliser :

• git log ou git log oneline pour identifier le commit qui t'intéresse ;
  
• git checkout <le numero du commit> pour basculer vers la version souhaitée ;
  
• git checkout master pour revenir au sommet de la branche master si c'est sur elle que tu travailles.

Il se peut que tu ne puisses pas basculer parce que tu as fait des modifications dans ton répertoire de travail et qu'il te faille les sauvegarder d'abord. Dans ce cas, soit tu fais un commit en bonne et due forme, soit tu fais git stash pour tout sauvegarder dans un coin (en fait, au sommet d'une branche spéciale). Après avoir visité ton historique puis être revenu à l'endroit initial, tu redéploies tes sauvegardes avec git stash pop et tu peux poursuivre ton travail normalement.

[benkunz]

merci Obsidian pour la réponse complète.

juste une chose, dans mon projet, j'ai deja "exclu" des fichiers avec la commande "git update-index --skip-worktree *.xlsx"
Du coup, le checkout ne passe pas.

error: Your local changes to the following files would be overwritten by checkout:
test.xlsx
Please commit your changes or stash them before you switch branches.
Aborting

j'ai tenté le "git stash", ca ne change rien. quant au git commit, je n'ai rien à commit vu que le fichier Excel est ignoré...

une idée ?

[benkunz]

et si je faisais mon checkout du vieux commit dans un nouveau dossier ?

j'ai créé un nouveau dossier, j'ai fait un git init dedans, et si je tente un git checkout <ID>, ca me dit "fatal: reference is not a tree"

il me manque probablement une sorte d'initialisation à faire pour pouvoir récupérer mon projet. une idée sur ce que je devrais faire ?

merci

[Obsidian]

merci Obsidian pour la réponse complète.

juste une chose, dans mon projet, j'ai deja "exclu" des fichiers avec la commande "git update-index --skip-worktree *.xlsx"

Houla, c'est peu être un peu tôt pour utiliser directement git update-index. Je n'ai personnellement jamais eu besoin d'y recourir pour le moment…
Si tu veux écarter de façon permanente certains fichiers du suivi (tes *.xlsx ou les produits de compilation par exemple), c'est plutôt vers .gitignore qu'il aurait fallu se tourner…

Sinon, « git stash » s'en tient par défaut aux fichiers qu'il suit. Tu peux lui demander de remiser tout l'état du working directory avec git stash -a. Ça devrait passer ensuite.

et si je faisais mon checkout du vieux commit dans un nouveau dossier ?

C'est possible mais ce n'est pas simple et surtout, ce n'est pas la manière de faire. On va déjà t'aider à maîtriser cette partie, donc.

[benkunz]

Si tu veux écarter de façon permanente certains fichiers du suivi (tes *.xlsx ou les produits de compilation par exemple), c'est plutôt vers .gitignore qu'il aurait fallu se tourner

j'utilise déjà le gitignore, mais j'avais oublié d'exclure les xlsx au départ du projet. Une fois commité, c'est trop tard, meme si tu rajoutes le fichier xlsx dans le gitignore, le fichier continuera a être suivi. Comment fais tu pour demander à git d'oublier un fichier deja commité ?

je vais tester le git stash -a

[Obsidian]

j'utilise déjà le gitignore, mais j'avais oublié d'exclure les xlsx au départ du projet. Une fois commité, c'est trop tard, meme si tu rajoutes le fichier xlsx dans le gitignore, le fichier continuera a être suivi. Comment fais tu pour demander à git d'oublier un fichier deja commité ?

Ça dépend si tu veux qu'il reste dans l'historique ou pas.

Si tu veux faire comme s'ils n'avaient jamais existé, il faut réécrire l'historique, soit avec git rebase -i s'il n'est pas trop long, soit avec git filter-branch qui est fait pour ça. Dans les deux cas, ce n'est pas forcément très difficile, mais ça nécessite d'avoir de la pratique quand même.

Si tu veux laisser l'historique en l'état (ce qu'il faut faire en général), alors cela veut dire qu'ils ont existé dans l'historique et qu'ils vont cesser d'exister à partir de cet instant. Il faut donc les supprimer, mais seulement dans l'index, en épargnant le working directory. Tu peux utiliser git rm --cached pour le faire. .gitignore va alors recommencer à l'ignorer. Le problème, c'est que cela t'empêche justement de revenir en arrière avec git checkout sur les versions qui le contienne encore. On aurait pu penser que cela provoquerait un message d'erreur mais c'est pire : comme il est dans l'historique et que git status déclare le dépôt propre à cause de .gitignore, le fichier concerné se fait écraser ! :-\

Le plus propre reste encore de refaire l'historique assez tôt avant publication. À défaut, le mieux reste effectivement --skip-worktree…

je vais tester le git stash -a

Tiens-nous au courant. ;-)

[benkunz]

bon et bien même avec le git stash -a, ça ne passe pas.

donc, je suis dans la situation où tout a déjà été commité, mais j'ai un fichier exclus via git update-index --skip-worktree a.xlsx dans mon dossier

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# git checkout 1abe2f140ce67898adec437fc6e386c52ee84bd1
error: Your local changes to the following files would be overwritten by checkout:
	a.xlsx
Please commit your changes or stash them before you switch branches.
Aborting


#git stash -a
Saved working directory and index state WIP on master: 3310590 update 2


# git checkout 1abe2f140ce67898adec437fc6e386c52ee84bd1
error: Your local changes to the following files would be overwritten by checkout:
	a.txt
Please commit your changes or stash them before you switch branches.
Aborting


# git status
On branch master
nothing to commit, working tree clean

ça ne veut pas...

[Obsidian]

Je remarque que ce n'est pas le même fichier (sauf si tu as retranscrit toi-même les messages d'erreur). On a a.xlsx dans un cas et a.txt dans l'autre.

C'est normal ?

[benkunz]

J’ai un doute, je te confirme tout ca ce soir

[benkunz]

Ça dépend si tu veux qu'il reste dans l'historique ou pas.

non, je veux les enlever. ici, c'est juste un oubli de ma part d'ajouter le fichier dans .gitignore. le fichier n'aura jamais du etre versionné.


pour l'histoire du a.txt/a.xlsx, je ne t'ai pas oublié, je te réponds ce soir

[Obsidian]

non, je veux les enlever. ici, c'est juste un oubli de ma part d'ajouter le fichier dans .gitignore. le fichier n'aura jamais du etre versionné.

Ok, dans ce cas, il va falloir que tu nous donnes l'âge approximatif de ton dépôt (s'il ne contient que quelques commits depuis le début ou s'il y en a des milliers), si tu as créé des branches distinctes ou pas, et à quel moment tu as commité les fichiers incriminés, en particulier si tu l'as fait depuis le commit initial.

Il y a plusieurs solutions, mais la plus appropriée dépendra de ces éléments.

[benkunz]

il va falloir que tu nous donnes l'âge approximatif de ton dépôt :

2 semaines

s'il ne contient que quelques commits depuis le début ou s'il y en a des milliers

une quinzaine

si tu as créé des branches distinctes ou pas

pas de branche

et à quel moment tu as commité les fichiers incriminés, en particulier si tu l'as fait depuis le commit initial.

des le début, car oubli de le mettre dans le .gitignore.

durant la journée, j'ai fait quelques tests de mon coté, et je crois avoir trouvé une solution, tu me diras ce que tu en penses
pour résumer la situation, le but est de pouvoir faire un git checkout <id> puis git checkout master, mais la manière dont j'ai exclus un fichier m'en empêche (git update-index --skip-worktree <file>)
voici ce que je propose :

• copie de <fichier> en dehors de mon projet pour le backuper
• git update-index --no-skip-worktree <fichier> (pour dire a git de s'occuper a nouveau du fichier oublier)
• git rm <fichier>
• je rajoute <fichier> dans .gitignore
• git commit
• je remets <fichier> dans mon projet. cette fois il n'est plus suivi par git

qu'en penses tu ?

[Obsidian]

• git rm <fichier>
• je rajoute <fichier> dans .gitignore
• git commit
• je remets <fichier> dans mon projet. cette fois il n'est plus suivi par git

qu'en penses tu ?

C'était en substance ce que je te proposais au commentaire au dessus, en effet, mais je me suis aperçu d'un détail rédhibitoire : si on conjugue un fichier .gitignore avec un fichier supprimé dans l'historique, alors ce fichier peut se faire écraser sans préavis si, justement, tu fais un git checkout d'une ancienne version.

Le mieux est donc de :

• Faire une copie préalable de tout le dépot (tu copies le répertoire entier quelque part) ;
• Lancer git filter-branch --index-filter 'git rm --ignore-unmatch a.xlsx' dans le dépôt principal.

Attention, cela va effacer le fichier du working directory, donc assure-toi de bien l'avoir sauvegardé d'abord.
Ensuite, tu crées ton fichier .gitignore et tu exclus tes fichiers Excel. Et enfin, tu ajoutes avec git add le fichier .gitignore lui-même.

[benkunz]

alors ce fichier peut se faire écraser sans préavis si, justement, tu fais un git checkout d'une ancienne version.

alors pas exactement, j'ai testé tout le process, et le checkout <id> n'a pas effacé mon fichier, par contre le checkout master OUI !!

je teste ta méthode demain

merci encore pour ton aide


voici toutes mes étapes si tu as assez de courage

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
mkdir testgit
cd testgit/
git init
vi a.log
vi a.php
git add a.log a.php
git commit -m "v0"
vi a.php
git commit -am "v1"
vi a.php
git commit -am "v2"
vi a.log
git commit -am "v3"
git update-index --skip-worktree a.log -> arrete de suivre
vi a.log 
git status -> ne montre plus que a.log a été modifié ! 
git ls-files -v . | grep ^S -> affiche bien a.log
git update-index --no-skip-worktree a.log
git status -> affiche que a.log a été modifé 
git rm a.log -f (faut mettre un -f car le fichier a été modifié)
git status -> le delete du fichier doit etre commité
git commit -m "v4"
git status -> RAS
vi .gitignore (add a.log)
git add .gitignore
git commit -am “gitignore”
git status -> RAS
vi a.log
vi a.php
git commit -am "v5"
git status -> RAS
ls -> a.log + a.php
git checkout d1b9c9bec950dd42e44c044a1832638f37e9148e 
HEAD is now at d1b9c9b v1 
ls -> a.log + a.php (donc a.log n’est pas effacé par checkout)
git status : HEAD detached at d1b9c9b. nothing to commit, working tree clean
git log -> on ne voit plus ce qu’il y a entre master et la version checkouté
git checkout master -> on revoit tous les logs. Le rollback est bien passé, mais a.log a été effacé !!

[Obsidian]

alors pas exactement, j'ai testé tout le process, et le checkout <id> n'a pas effacé mon fichier, par contre le checkout master OUI !!

Oui, c'est « normal » : git checkout doit s'appuyer sur les routines de git status pour lui confirmer que le dépôt est clean avant de basculer vers une autre version (justement pour éviter d'écraser des choses non suivies), sauf que le fichier .gitignore lui faire précisément dire que c'est propre parce que les fichiers concernés sont ignorés.

Donc en revenant en arrière, le fichier se fait écraser par l'ancienne version (ce qui est le comportement attendu lorsque le fichier est suivi, et il l'était bien dans le passé). Ensuite, en revenant à la dernière version, on avait pris acte du fait qu'il a été effacé à un moment donné et qu'on en était resté là. Donc il l'efface.

On ne peut même pas dire que ce soit un « bug » à proprement parler, en réalité, puisque ce serait toujours le comportement attendu dans le cas d'un fichier auto-généré, par exemple le produit d'une compilation. Par contre, c'est effectivement une subtilité qu'il faut prendre en compte dès le départ.

voici toutes mes étapes si tu as assez de courage

Un peu tard pour ce soir, je mets le nez dedans demain. ;-)

[benkunz]

je voulais comprendre un peu plus en détail ce que tu m'as suggéré, et ca me fait peur

je cite :
git filter-branch has a plethora of pitfalls that can produce non-obvious manglings of the intended history rewrite (and can leave you with little time to investigate such problems since it has such abysmal performance). These safety and performance issues cannot be backward compatibly fixed and as such, its use is not recommended (https://git-scm.com/docs/git-filter-branch)

je crois que j'ai trouvé plus simple, et moins surtout moins risqué. Donc j'ai mon site appli web qui tourne dans le dossier "MonSite". Dans ce dossier MonSite, j'ai le dossier .git.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
#ls 
MonSite
# mkdir test
# cd test
# cp ../MonSite/.git .
# git checkout <commitID>

et hop, basta. à ce niveau, j'ai tout ce qu'il me faut. Dans le dossier MonSite, j'ai le site actuel, et dans test, j'ai mon ancienne version. J'ai les 2 en parallèle pour tester des différences. quand j'ai fini de comparer, j'efface test. qu'en penses tu ? t'y vois un inconvénient ?

merci encore pour le temps que tu y passes

[Obsidian]

je voulais comprendre un peu plus en détail ce que tu m'as suggéré, et ca me fait peur je cite :
git filter-branch […]

Oui, enfin c'est ni totalement vrai ni totalement faux. Comme indiqué, git filter-branch sert à filtrer une branche ou, plus précisément, la faire passer à travers un filtre. En substance, il s'agit en fait de reprendre chaque commit un par un, de les amender en lançant automatiquement la commande passée en paramètre et de les rejouer. C'est pratique aussi parce qu'il va gérer lui-même le cas du commit initial (plus délicat avec un simple git rebase -i) par exemple.

C'est donc un wrap-around autour de primitives existantes et, parallèlement, le message indique qu'il y a beaucoup de subtilités à prendre en compte quand on veut utiliser cette commande… le cas de figure qui t'intéresse en ce moment en étant justement un !

Le mieux, comme indiqué au dessus, reste bien de faire une copie complète de ton dépôt (comme ça, si tu le casses, tu pourras le re-générer à volonté et sans difficulté) et de lancer la commande en question. Pour info, je l'ai vérifiée moi-même sur un dépôt de test en local sur ma machine avant de la publier. ;-)

je crois que j'ai trouvé plus simple, et moins surtout moins risqué. Donc j'ai mon site appli web qui tourne dans le dossier "MonSite". Dans ce dossier MonSite, j'ai le dossier .git.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
#ls 
MonSite
# mkdir test
# cd test
# cp ../MonSite/.git .
# git checkout <commitID>

et hop, basta. à ce niveau, j'ai tout ce qu'il me faut. Dans le dossier MonSite, j'ai le site actuel, et dans test, j'ai mon ancienne version. J'ai les 2 en parallèle pour tester des différences. quand j'ai fini de comparer, j'efface test. qu'en penses tu ? t'y vois un inconvénient ?

Si c'est juste pour accéder une seule fois au commit qui t'intéresse, ça fonctionnera ponctuellement, mais ça ne résoudra pas le problème. Tu seras obligé de faire cette manipulation à chaque fois et cela va devenir de plus en plus délicat à mesure que le dépôt grossira, alors que c'est censé être une des fonctionnalités les plus fondamentales de tout logiciel de versioning.

Prend le temps de le mettre au propre maintenant, tant qu'il est petit, pour ne plus jamais avoir à y revenir ensuite. ;-)

[benkunz]

Bonjour Obsidian, je me suis lancé dans la réécriture de mes commits. J’avais cru comprendre qu’en faisant des git checkout <commit id>, j’allais etre capable de me retrouver a un etat antérieur, mais lorsque je fais ca, il me manque certains fichiers. Je precise que pour ne rien casser, je travaille sur un dossier en parallèle, donc je crée un dossier vide, j’y copie colle le dossier .git puis je checkout une ancienne version.
Il doit bien y avoir une raison mais elle m’échappe. Est ce que le git checkout <commit id> doit remettre le dossier dans l’etat dans lequel il etait au moment du commit, ou est ce qu’il applique dans mon dossier vide seulement les changements contenus dans <commit id> ? Si c’est la 2eme option, alors quelle commande git je peux faire pour retrouver mon dossier dans l’etat au moment du commit ?
Merci

[Obsidian]

Bonjour,

Bonjour Obsidian, je me suis lancé dans la réécriture de mes commits. J’avais cru comprendre qu’en faisant des git checkout <commit id>, j’allais etre capable de me retrouver a un etat antérieur, mais lorsque je fais ca, il me manque certains fichiers.

A priori, c'est normal si tu reviens à un état où ils n'existaient pas encore.

Je precise que pour ne rien casser, je travaille sur un dossier en parallèle, donc je crée un dossier vide, j’y copie colle le dossier .git puis je checkout une ancienne version.

C'est une bonne chose, mais si tu copies le répertoire .git, tu recrées un dépôt pour ainsi dire à l'identique, et tu vas avoir le même problème qu'au début tant que tu n'auras pas filtré ta branche.

Il doit bien y avoir une raison mais elle m’échappe. Est ce que le git checkout <commit id> doit remettre le dossier dans l’etat dans lequel il etait au moment du commit, ou est ce qu’il applique dans mon dossier vide seulement les changements contenus dans <commit id> ? Si c’est la 2eme option, alors quelle commande git je peux faire pour retrouver mon dossier dans l’etat au moment du commit ?
Merci

Non, c'est bien la première option qui est valide… mais cela ne concerne que les fichiers qui sont suivis par Git, c'est-à-dire ceux qui ont été ajoutés au moins une fois dans l'historique du dépôt. Git, d'ailleurs, ne vide jamais le dépôt entièrement avant de le reconstruire quand on change de version. Il ne fait qu'effacer et recréer les fichiers suivis qui ont besoin de l'être.

Ça veut dire que tous les autres fichiers du dépôt — en particulier ceux ignorés à l'aide de .gitignore — restent inchangés et immuables (modulo le bug qui nous occupe ici). Mais si tu copies manuellement le dépôt ailleurs, git checkout ne va bien sûr pas reconstituer ces fichiers-là.