Version imprimable
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
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.
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 ?
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
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…Citation:
Envoyé par 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…
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.
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.Citation:
et si je faisais mon checkout du vieux commit dans un nouveau dossier ?
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é ?Citation:
Envoyé par Obsidian
je vais tester le git stash -a :)
Ça dépend si tu veux qu'il reste dans l'historique ou pas.Citation:
Envoyé par benkunz
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…
Tiens-nous au courant. ;-)Citation:
je vais tester le git stash -a :)
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
ça ne veut pas...Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
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 ?
J’ai un doute, je te confirme tout ca ce soir
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é.Citation:
Envoyé par Obsidian
pour l'histoire du a.txt/a.xlsx, je ne t'ai pas oublié, je te réponds ce soir :)
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.Citation:
Envoyé par benkunz
Il y a plusieurs solutions, mais la plus appropriée dépendra de ces éléments.
2 semainesCitation:
Envoyé par Obsidian
une quinzaineCitation:
s'il ne contient que quelques commits depuis le début ou s'il y en a des milliers
pas de brancheCitation:
si tu as créé des branches distinctes ou pas
des le début, car oubli de le mettre dans le .gitignore.Citation:
et à quel moment tu as commité les fichiers incriminés, en particulier si tu l'as fait depuis le commit initial.
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 ?
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.Citation:
Envoyé par benkunz
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.
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 !!Citation:
alors ce fichier peut se faire écraser sans préavis si, justement, tu fais un git checkout d'une ancienne version.
je teste ta méthode demain
merci encore pour ton aide
voici toutes mes étapes si tu as assez de courage
Code:
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
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.Citation:
Envoyé par benkunz
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.
Un peu tard pour ce soir, je mets le nez dedans demain. ;-)Citation:
voici toutes mes étapes si tu as assez de courage
je voulais comprendre un peu plus en détail ce que tu m'as suggéré, et ca me fait peur 8O
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.
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 ?Code:
2
3
4
5
6
merci encore pour le temps que tu y passes :)
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.Citation:
Envoyé par benkunz
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. ;-)
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.Citation:
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.
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 ?Code:
2
3
4
5
6
Prend le temps de le mettre au propre maintenant, tant qu'il est petit, pour ne plus jamais avoir à y revenir ensuite. ;-)
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
Bonjour,
A priori, c'est normal si tu reviens à un état où ils n'existaient pas encore.Citation:
Envoyé par benkunz
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.Citation:
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.
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.Citation:
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
Ç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à.