Discussion :

[Wilhem31]

Bonjour,

Tout d'abord, désolé de poster un nouveau commentaire sur le forum dû à mes erreurs. Pourtant, je fais le maximum pour réussir à utiliser Git proprement, de plus j'ai vu que j'avais posté un message il y a peine de mois déjà…
Voila, encore une fois, petit problème : mon début de versionning était plutôt bien parti, une branche master où je merge quand des fonctionnalités sont OK, une branche de dev ou je merge mes branches annexes. Jusqu'ici ça marchait pas mal.

Le problème, c'est qu'un fichier de Symfony est venu me perturber et en voulant le supprimer du repo et l'ajouter a .gitignore, j'ai fait n'importe quoi…

Du coup, maintenant je me retrouve avec ça :



Un sacré merdier que je n'arrive plus à comprendre, j'ai l'impression que ma branche dev est la master sont la même et j'ai une branche sur laquelle j'étais features/TwigBundle que j'ai essayé de merger sur ma dev mais qui pointe aussi sur la même branche que les autres ?

Du coup, j'ai voulu créer une nouvelle branch development pensant que ca résoudrait le problème mais j'en suis pas vraiment suû, de plus je ne comprends pas les remotes/origin/dev et remotes/origin/master ...
Du coup que pensez-vous que je dois faire à cet instant ?

Merci...

[Obsidian]

Salut,

La bonne nouvelle, c'est qu'avec Git, il est pratiquement impossible de perdre des données (à part peut-être avec un git reset --hard) et qu'il est assez facile de retrouver l'état que l'on souhaite atteindre, quel qu'il soit. La mauvaise, c'est qu'il faut être sûr d'avoir compris comment fonctionnent les deux ou trois concepts fondamentaux (qui en fin de compte sont assez simples eux-aussi) parce qu'on ne peut pas y arriver en tâtonnant. Tu vas juste continuer à mélanger ton dépôt plus encore qu'il l'est.

Le problème, c'est qu'un fichier de Symfony est venu me perturber et en voulant le supprimer du repo et l'ajouter a .gitignore, j'ai fait n'importe quoi…

C'est-à-dire ? Qu'as-tu fait en particulier ?
Ça nous aiderait beaucoup de savoir quelles commandes tu as lancées, même partiellement. Si tu travailles en ligne de commande, regarde dans l'historique.

Un sacré merdier que je n'arrive plus à comprendre, j'ai l'impression que ma branche dev est la master sont la même

C'est tout-à-fait possible et c'est même normal si tu as fait une fusion (merge). C'est possible également si tu as forcé (avec « -f ») la création d'une branche déjà existante. Dans ce dernier cas, d'ailleurs, si tu n'as pas précisé de destination explicite, c'est sur l'emplacement courant que cela s'applique. Et si tu était « sur une branche » (donc probablement à la tête de celle-ci), tu auras créé la nouvelle au même endroit, te donnant l'impression que ce sont les mêmes.

Du coup, j'ai voulu créer une nouvelle branch development pensant que ca résoudrait le problème mais j'en suis pas vraiment suû, de plus je ne comprends pas les remotes/origin/dev et remotes/origin/master ...

• « remote » est le nom donné au « répertoire » qui recense tous les dépôts distants associés au tien (en principe, un seul par défaut, si tu as simplement fait un « git clone » d'un dépôt existant) ;
• « origin » est le nom par défaut donné à ton dépôt distant si tu ne le précises pas explicitement (là encore, automatique dans le cas d'un git clone) ;
• « remotes/origin/dev » et « remotes/origin/master » sont des noms de branche situées sur le dépôt distant mais dont ton Git local conserve la trace. Et plus précisément, ce sont les alter-égo de tes branches locales. Celles-ci sont paramétrées pour être associées avec ces branches distantes et quand tu fais « git pull » ou « git push », Git sait ainsi de quelle branche vers quelle autre branche il faut reporter les nouveautés.

Il faut aussi savoir que :

• Git est un système à snapshots. Chaque fois que tu modifies un fichier, il le réécrit entièrement. Mais si ton fichier revient à un état antérieur déjà connu, il s'en rend compte aussi et retrouve cet état ;
• Un dépôt Git est un graphe orienté acyclique (DAG). Mais plus précisément, ce sont les commits eux-mêmes qui structurent le dépôt car chaque commit référence lui-même le précédent (ou LES précédents en cas de fusion). Du coup, une branche est simplement une étiquette qui référence le dernier commit en date, ce qui, de là, nous permet de « remonter le fil » et de retrouver toute la lignée. La seule chose qui va distinguer une branche d'un simple tag est que le fait qu'étant qualifiée comme telle, elle va automatiquement être mise à jour chaque fois que l'on va ajouter un nouveau commit là où un tag restera où il est si on ne lui dit pas de bouger.

Sache également qu'il existe les reflogs (facultatifs mais créés par défaut au moins pour master), qui sont un historique des changements de chaque branche. Donc, si tu as déplacé ta branche par accident et que tu ne sais plus où elle était juste avant, la première chose à faire est un git reflog <tabranche> pour voir où elle était.

Je vois que tu as une branche « stash » en suspens. Tu as probablement fait un git stash qui a remisé les dernières modifications que tu avais faites à ce moment-là et ramené ton dépôt au dernier état connu à l'époque, ce qui t'as donné l'impression qu'il était propre. C'était peut-être vrai et les modifs que tu as remisées n'ont peut-être pas beaucoup d'importance, mais elles vont rester en attentes ad vitam æternam ou, au moins, jusqu'au moment où tu te serviras à nouveau de stash et risquent donc de ressortir à moment complètement inattendu.

Enfin, il semble que la dernière chose que tu aies faite tout en haut soit fusionner master et developpement. Je vois même écrit « conflict ok ». J'espère simplement que c'est vrai car Git te demande en principe de résoudre ces conflits et te fais confiance quand tu lui dis que c'est le cas.

et j'ai une branche sur laquelle j'étais features/TwigBundle que j'ai essayé de merger sur ma dev mais qui pointe aussi sur la même branche que les autres ?

Non, elle est toujours au même endroit. Par contre, on voit que la branche master (aujourd'hui un peu plus haute) l'a bien intégrée à un moment de son histoire. Quand tu fais un merge explicite, Git fusionne en fait l'état du dépôt tel qu'il apparaît des deux côtés et produit un commit sur la branche courante qui est censé mettre celle-ci dans un état qui correspond justement à cette fusion. Donc c'est ce commit-là qui va bien contenir les changements en réalité, et qui va se référer à ses deux parents. Ici, ça correspond à celui qui est marqué « bug idea ». Mais du coup, le descripteur de la branche fusionnée, lui, reste où il se trouve. Il peut même, d'ailleurs, continuer à vivre sa vie en parallèle mais dans le cas d'un workflow de développement, il est plus intéressant de faire redémarrer une nouvelle branche de développement depuis l'état de la branche principale.

Du coup que pensez-vous que je dois faire à cet instant ?

À vue de nez, je pense qu'il « suffirait » de ramener chaque branche (master et dev) sur leurs précédents commit respectifs en date, mais impossible d'être catégorique sans en savoir un peu plus sur ta situation.

[Wilhem31]

Concernant les history ca donne a peu pres ca :

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
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
  503  git commit -m " 404 exception add "
  504  git checkout dev
  505  git merge features/ExceptionTwig
  506  git checkout master
  507  git add .
  508  git commit -m " Merge feature/ExceptionTwig"
  509  git checkout master
  510  git chekout dev
  511  git checkout dev
  512  git push origin dev
  513  git checkout master
  514  git merge dev
  515  git add .
  516  git status
  517  git push origin master
  518  git status
  519  git merge dev
  520  git commit -m "merge dev"
  521  git merge dev
  522  git stash
  523  git push origin master
  524  git status
  525  git stash list
  526  git stash apply
  527  git status
  528  git add .
  529  git commit -m"stash apply"
  530  git status
  531  git push origin master
  532  git checkout dev
  533  git checkout dev
  534  git add .
  535  git commit -m" stash"
  536  git checkout dev
  537  git status
  538  git checkout master
  539  git status
  540  git push origin master
  541  git status
  542  rm .idea/workspace.xml
  543  git status
  544  git rm -r .idea
  545  git commit -m" remove .idea from repo"
  546  git status
  547  git push origin master
  548  git status
  549  git checkout dev
  550  git rm -r .idea/workspace.xml
  551  git rm -r .idea
  552  git checkout dev
  553  git status
  554  git add
  555  git add .
  556  git checkout dev
  557  mv .idea ../.idea_backup
  558  rm .idea
  559  git rm -r .idea
  560  git commit -m" remove .idea from repo"
  561  mv ../.ideabackup .idea
  562  git status
  563  git checkout dev
  564  git checkout features/TwigException
  565  git branch
  566  git checkout features/ExceptionTwig
  567  git checkout dev
  568  mv .idea ../.idea_backup
  569  rm .idea
  570  mv ../.ideabackup .idea
  571  git rm -r .idea
  572  git commit -m"remove idea from repo"
  573  git checkout dev
  574  git merge features/ExceptionTwig
  575  git status
  576  git commit-"idea rm from repo"
  577  git commit-m"idea rm from repo"
  578  git commit -m"idea rm from repo"
  579  git rm idea
  580  git rm .idea
  581  git merge features/ExceptionTwig
  582  git add .
  583  git merge features/ExceptionTwig
  584  git commit -m"bug idea"
  585  git merge features/ExceptionTwig
  586  git checkout master
  587  git reset --hard HEAD
  588  git reset --hard HEAD
  589  git reset --hard HEAD
  590  git checkout 9712e0c3e71e7d9e8c618ae0cec27cd4e862314f
  591  git stash
  592  git checkout 9712e0c3e71e7d9e8c618ae0cec27cd4e862314f
  593  git checkout master
  594  git checkout master
  595  git checkout master
  596  git rm .idea
  597  git rm -r .idea
  598  git rm -f .idea
  599  git rm -r-f .idea
  600  git mv .idea ../.idea_backup
  601  mv .idea ../.idea_backup
  602  git status
  603  git add .
  604  git status
  605  git commit -m"head detached"
  606  git checkout master
  607  git branch Dev b2f2fccf
  608  git checkout dev
  609  git rm -r .idea/
  610  git rm -r .idea
  611  git status
  612  mv .idea ../.idea_backup
  613  git status
  614  git add
  615  git add .
  616  git status
  617  git commit -m" test gitignore"
  618  git status
  619  git push origin master
  620  git status
  621  git checkout dev
  622  mv .idea ../.idea_backup
  623  rm .idea
  624  git rm -r .idea/
  625  git rm -r .idea/ -f
  626  git status
  627  git checkout dev
  628  git commit -m " idea delete"
  629  git push origin master
  630  git status
  631  git status
  632  git add .gitignore
  633  git commit -m " gitignore update "
  634  git push origin master
  635  git status
  636  git checkout dev
  637  git status
  638  git checkout master
  639  git rm -r .idea/ -f
  640  git status
  641  git commit -m"idea delete to dev"
  642  git push origin dev
  643  git status
  644  git update-index --assume-unchanged .idea/
  645  git status
  646  git checkout master
  647  git checkout dev
  648  git status
  649  git add .
  650  git commit -m " gitignore update from dev"
  651  git push origin dev
  652  git status
  653  git checkout dev
  654  git checkout master
  655  git merge dev
  656  git commit " conflict ok"
  657  git add .
  658  git commit -m" conflict ok"
  659  git status
  660  git push origin master
  661  git checkout dev
  662  git status
  663  git checkout features/ExceptionTwig
  664  git checkout dev
  665  git branch features
  666  git checkout features/ExceptionTwig
  667  git checkout dev
  668  git checkout master
  669  git branch development
  670  git checkout development
  671  git checkout master

En fait au début j'arrivais a peu pres a gérer mes branches correctement, mais au moment ou j'ai eu un fichier qui m’empêchait de changer de branch j'ai donc essayé de le supprimer d'abord sur master mais apres je l'ai eu sur toutes mes branch et la c'était la panique je me suis embrouillé entre ça et les stash !

Effectivement j'ai fait un merge de dev vers master quand j'avais fini de corriger quelques bugs mais maintenant a chaque fois que je change de branch elle se place derrière mon master.

Bien sur, j'ai fait trois git reset --hard comme tu le vois ... tout faux quoi.

Par contre comme tu vois sur la photo ce n'est pas la branch development que j'ai mergé mais bien dev, j'ai essayé de recréer cette branch en me disant que je pourrait peut etre repartir sur celle ci comme branch de dev avec d'autre branch features dessus mais ca n'est pas le cas. Toutes mes branch viennent se placer derriere master...

J'aimerai arriver a repartir sur mon master qui est en place, ma branch de dev qui repart de son coté mais ça m'a l'air coton la ...

[Obsidian]

Bien sur, j'ai fait trois git reset --hard comme tu le vois ... tout faux quoi.

Pas de panique. Ce que tu risquerais d'avoir perdu au pire, ce serait les modifications en cours dans ton répertoire de travail avant de les avoir commitées au moins une fois. Si tu avais coupé ta branche en la ramenant trop en amont dans l'historique, les commits associés ne seraient plus visibles mais ils continueraient d'exister dans ton dépôt pendant au moins trois mois, à condition d'être capable de les retrouver (en utilisant notamment le reflog pour ça, mais également les éventuels tags ou d'autres branches qui dériveraient du même endroit). Mais là, de toutes façons, tu as appelé trois fois la commande successivement sur HEAD, donc sur l'emplacement courant. Aucun risque d'avoir tronqué la branche, donc.

En fait au début j'arrivais a peu pres a gérer mes branches correctement, mais au moment ou j'ai eu un fichier qui m’empêchait de changer de branch j'ai donc essayé de le supprimer d'abord sur master mais apres je l'ai eu sur toutes mes branch et la c'était la panique je me suis embrouillé entre ça et les stash !

Encore une fois, il faut se souvenir qu'une branche, sous Git, n'est pas un « sous-dépôt » dans lequel le développement évoluerait en parallèle des autres, mais un emplacement dans ton graphe. Quand tu fais un checkout sur un nom de branche, tu déplaces la tête HEAD à cet emplacement et tu passes en mode « attaché », c'est-à-dire que tu lies l'état de la branche à celui de HEAD jusqu'au prochain checkout, de sorte que chaque fois que tu commites, cette branche est automatiquement mise à jour pour pointer le dernier en date.

Ça veut dire également que chaque fois que tu fais un checkout sur un nom de tag, sur la somme SHA1 d'une révision quelconque ou sur un nom de branche, l'opération est la même (hormis le fait de passer en attaché ou détaché quand on saute vers une branche). Et ce comportement est simple : Git modifie, dans le répertoire de travail, les fichiers suivis (ceux qui listés dans le commit concerné, y compris s'il s'agit de les supprimer) et laisse tel quel tous les autres (par exemple les fichiers de compilation).

Donc, si tu as un fichier marqué comme non suivi dans ton dépôt, c'est normal de le voir apparaître dans git status quelle que soit la branche où tu te trouves…

A contrario, si tu modifies un fichier suivi (déjà commité une fois) et que tu demandes à faire un checkout quelque part, alors Git va s'abstenir car l'opération écraserait son contenu et tes modifs seraient alors perdues. Si c'est ce que tu veux faire quand même, tu peux forcer le checkout avec git checkout -f ou un git reset --hard, justement, quand tu veux ramener une branche en arrière.

Quand tu es confronté à ça, soit tu enregistres en bonne et due forme cette modification (tu fais un commit), soit tu sauvegardes le fichier et tu forces le déplacement (mais c'est un peu bête de ne pas utiliser les fonctionnalités prévues à cet effet), soit encore tu utilises git stash pour remiser temporairement tout ce qui « dépasse », ramener ton dépôt dans l'état du dernier commit et, ainsi, pouvoir faire tes déplacements tranquillement. Quand tu as fini, tu reviens à ton point de départ et tu fais un git stash pop pour dépiler tes modifs, revenir à l'état où étais au départ, et poursuivre ton développement.

Effectivement j'ai fait un merge de dev vers master quand j'avais fini de corriger quelques bugs mais maintenant a chaque fois que je change de branch elle se place derrière mon master.

Je ne sais pas ce que tu entends par « elle se place derrière mon master » mais il est normal, en effet, que depuis master, tu la retrouves dans l'historique. Par contre, tu peux la déplacer (de force, si nécessaire). Tu peux aussi l'effacer officiellement et recréer une branche du même nom, ce qui revient exactement au même (y compris techniquement).

Par contre comme tu vois sur la photo ce n'est pas la branch development que j'ai mergé mais bien dev, j'ai essayé de recréer cette branch en me disant que je pourrait peut etre repartir sur celle ci comme branch de dev avec d'autre branch features dessus mais ca n'est pas le cas. Toutes mes branch viennent se placer derriere master...

Oublie-les pour le moment, on va repartir au propre.

J'aimerai arriver a repartir sur mon master qui est en place, ma branch de dev qui repart de son coté mais ça m'a l'air coton la ...

Bien. Fais déjà un :

Code Shell :

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

git status

… pour voir si tu as des modifications en suspens. Si c'est le cas, fais d'abord un :

Code Shell :

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

git stash list

… pour voir si tu avais déjà remisé du bazar qu'il faudrait qu'on traite a posteriori. Ensuite, qu'il y en ait ou pas, fais un :

Code Shell :

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

git stash

… pour remiser tout ce qui est en suspens. Stash fonctionne comme une pile, donc tu n'écraseras pas ce qui était déjà remisé avant, le cas échéant. Fais ensuite un :

Code :

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

git checkout master

… pour te déplacer à la tête de ta branche principale. Et là, fais le bilan de ce qu'il te manque. Fais enfin un :

Code :

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

git status

… à nouveau pour voir s'il y a des fichiers non suivis qui devraient l'être à ce stade du développement.

Une fois que cette première étape sera propre, on verra ensuite comment auditer le reste de tes branches et importer ce qui doit l'être avant de les faire redémarrer ailleurs.

[Wilhem31]

Déjà un grand merci pour ton aide et surtout pour les détails et l'apprentissage que ça amene, en plus du temps que tu prends.
Je pense qu’après ça je vais me faire un tp sur git complet ou un un entrainement sur un projet test pour pallier les différentes lacunes que j'ai!

Du coup, pour le premier git status que tu m'as dis, je ne sais pas sur quelle branch il fallait que je me place mais de toute façon j'ai :
nothing to commit, working tree clean pour mes branch master dev developement
Pour ma branch features/ExceptionTwig j'ai toujours ce untracked file du fichier .idea que je cherche à supprimer du repo !

Pour le git stash list j'ai eu 4 résultats :

stash@{0}: WIP on dev: 3da7884 bug idea
stash@{1}: WIP on master: 44e68a7 merge dev
stash@{2}: WIP on master: 098f2cc erreur
stash@{3}: WIP on master: a783fac Bug cache

et j'ai donc fait le git stash : no local changes to save

et en revenant sur le master avec un git status : nothing to commit, working tree clean pour mes branch master dev developement

[Obsidian]

Bonjour,

Déjà un grand merci pour ton aide et surtout pour les détails et l'apprentissage que ça amene, en plus du temps que tu prends.
Je pense qu’après ça je vais me faire un tp sur git complet ou un un entrainement sur un projet test pour pallier les différentes lacunes que j'ai!

C'est une bonne idée, mais les seuls points qu'il faut comprendre, à mon avis, parce que tout le reste en découle naturellement ensuite sont pour moi :

• Le système d'objet ;
• Le fonctionnement de l'index.

Quand ces choses-là sont claires, tout le reste le devient automatiquement (ou presque).

Du coup, pour le premier git status que tu m'as dis, je ne sais pas sur quelle branch il fallait que je me place mais de toute façon j'ai :
nothing to commit, working tree clean pour mes branch master dev developement

Bien. Donc c'est propre pour le moment.

Pour ma branch features/ExceptionTwig j'ai toujours ce untracked file du fichier .idea que je cherche à supprimer du repo !

D'abord, si tu veux supprimer, à un moment ou un autre, un fichier d'une branche, il faut le dire à Git : « git rm <fichier> ». L'opération supprimera le fichier du working directory et planifiera sa disparition pour le prochain commit (comme avec git add). Mais en relisant ton historique, je m'aperçois que tu le fais. Ensuite, il faut se souvenir que dès lors, le fichier n'existera plus mais « aura existé ». Ça signifie que si tu fais un checkout sur une version plus ancienne de ta branche, il est normal de voir le fichier réapparaître.

Ensuite, c'est normal qu'un fichier qui se trouve dans ton dépôt mais pas dans le dernier commit en date apparaisse comme « untracked ». Et effectivement, si c'est un fichier qui est généré automatiquement, il faut le mettre dans .gitignore. Maintenant, il est possible et même probable que « .gitignore » lui-même soit suivi et enregistré au fil de tes commits. Donc, si tu reviens en arrière en faisant un checkout sur une branche plus ancienne, tu récupères une version plus ancienne de .gitignore également, dans laquelle tu n'avais pas encore ajouté cette exception, ce qui fait donc réapparaître le fichier dans la liste des non-suivis.

Par contre, ce qui est curieux dans ton schéma, c'est que features/ExceptionTwig référence un commit « orphelin », qui a ensuite été fusionné dans la branche principale (ou la branche de dev, dur à dire). C'est possible, mais c'est très irrégulier en soi et Git refuse en principe de faire la fusion si on ne lui passe pas une option explicite pour autoriser l'opération. Donc, il est assez curieux que tu te retrouves avec ce genre de choses. As-tu utilisé un outil graphique pour produire cette révision ? Ou a-t-elle été introduite par un framework tiers ?

Pour le git stash list j'ai eu 4 résultats :

stash@{0}: WIP on dev: 3da7884 bug idea
stash@{1}: WIP on master: 44e68a7 merge dev
stash@{2}: WIP on master: 098f2cc erreur
stash@{3}: WIP on master: a783fac Bug cache

Ce sont les quatre remisages successifs que tu as fait un peu partout et qui, à chaque fois, ont mis temporairement de côté les différences du working directory avec l'état de ta branche. On verra plus tard ce qu'ils contiennent mais il est probable qu'on puisse à terme se contenter de les abandonner, purement et simplement.

et j'ai donc fait le git stash : no local changes to save

Normal si le dépôt est propre (et c'est très bien comme ça).

et en revenant sur le master avec un git status : nothing to commit, working tree clean pour mes branch master dev developement

Je te propose déjà de mettre des tags aux emplacements courants de tes branches, pour que l'on puisse éventuellement y revenir si jamais quelque chose devait mal tourner :

Code Shell :

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

1
2
3
4
5
git tag master20180418 master
git tag dev20180418 dev
git tag development20180418 development
git tag commandeTest20180418 commandeTest
git tag featExceptionTwig20180418 features/ExceptionTwig

Le numéro en suffixe est simplement la date d'aujourd'hui, pour que tu puisses facilement les identifier dans le futur et les supprimer une fois que ton dépôt sera réputé propre.
Ensuite, saute vers master si ce n'est pas encore fait :

Code Shell :

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

git checkout master

Vérifie si le fichier « .idea/… » se trouve bien dans .gitignore, et surtout si tes fichiers de développement sont bien à jour sur cette version.
Si c'est le cas, tu peux forcer ta branche « dev », par exemple, à repartir de ce point :

Code Shell :

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

git branch -f dev

… et tu peux faire la même chose avec « development » et avec les autres branches qui auraient besoin de repartir de ce point aussi. À l'issue de ces opérations, toutes les étiquettes « vertes » seront en tête de ton schéma et tu auras des tags (étiquettes jaunes fléchées) à leurs anciens emplacements.

Par contre, étant donné que tu as forcé le déplacement de tes branches, tu auras probablement de les forcer (une seule fois chacune) sur le serveur distant quand tu feras un git push.


Pour la suite, souviens-toi que lorsque tu fais git merge, Git intègre sur la branche courante les variations observées sur l'état de la branche que tu veux fusionner. Il génère donc un commit qui se réfère aux deux branches MAIS la branche « fusionnée », elle, reste en réalité inchangée, c'est-à-dire qu'elle pointe toujours le même commit. C'est ce que l'on observe sur ton graphique. La branche master correspond visiblement à la ligne rouge, à la base. Même si elle zigue-zague, elle évolue jusqu'à « gitignore update ». Parallèlement, tu ajoutes deux commits sur ta branche dev (« idea delete to dev » et « git ignore from dev ») qui apparaissent en tête de schéma parce que ce sont les derniers en date. Enfin, tu fais une fusion des deux : master, qui est la branche courante, avance bien d'un cran (à « conflicts ok ») mais dev reste à sa place.

[Wilhem31]

D'abord, si tu veux supprimer, à un moment ou un autre, un fichier d'une branche, il faut le dire à Git : « git rm <fichier> ». L'opération supprimera le fichier du working directory et planifiera sa disparition pour le prochain commit (comme avec git add). Mais en relisant ton historique, je m'aperçois que tu le fais. Ensuite, il faut se souvenir que dès lors, le fichier n'existera plus mais « aura existé ». Ça signifie que si tu fais un checkout sur une version plus ancienne de ta branche, il est normal de voir le fichier réapparaître

Du coup a chaque branch anciennement crée et encore active il faut faudra faire la commande c'est ça ?

Par contre, ce qui est curieux dans ton schéma, c'est que features/ExceptionTwig référence un commit « orphelin », qui a ensuite été fusionné dans la branche principale (ou la branche de dev, dur à dire). C'est possible, mais c'est très irrégulier en soi et Git refuse en principe de faire la fusion si on ne lui passe pas une option explicite pour autoriser l'opération. Donc, il est assez curieux que tu te retrouves avec ce genre de choses. As-tu utilisé un outil graphique pour produire cette révision ? Ou a-t-elle été introduite par un framework tiers ?

Il me semble que c'est à la suite d'un stash aussi que j'ai eu ce probleme avec un " HEAD Detached " à la suite, mais ce qui m'amene en général des erreurs c'est vraiment le stash, où je ne comprends pas tout. Du coup, j'ai pris la mauvaise habitude de commit des que je fais une modif ce qui n'est pas une bonne solution je pense.

Je viens de faire les 4 git stash et par contre j'ai l'impression d'avoir perdu des données , dont des methodes pour faire des requetes sql sur mes objets

[Obsidian]

Du coup a chaque branch anciennement crée et encore active il faut faudra faire la commande c'est ça ?

Non, justement. On repart au propre sur ton point de départ et même si les branches de développement et autres portent le même nom, elles démarreront toutes désormais de l'état actuel de master et tu n'auras plus besoin de te soucier du passé (même si tu pourras toujours t'y référer si tu en as besoin).

C'est très différent de certains autres VCS et notamment de Mercurial dans lequel les branches, mêmes condamnées, existent ad vitam æternam.

Il me semble que c'est à la suite d'un stash aussi que j'ai eu ce probleme avec un " HEAD Detached " à la suite, mais ce qui m'amene en général des erreurs c'est vraiment le stash, où je ne comprends pas tout. Du coup, j'ai pris la mauvaise habitude de commit des que je fais une modif ce qui n'est pas une bonne solution je pense.

Peu probable. Ni stash ni l'état détaché ne provoquent ce genre de choses.

Sur le fond, « to stash » veut littéralement dire « remiser » ou « mettre de côté » pour préserver quelque chose, voire même « entasser ton son fourbi dans le placard pour faire place nette le temps qu'il faut », ce qui est exactement ce que l'on cherche à faire. Donc, quand on a besoin de se déplacer et qu'on a des modifications en suspens, il suffit d'appeler git stash pour sauvegarder l'état courant de ton dépôt, faire ses déplacements et le restaurer ensuite.

Et dans les faits, Git va en fait composer un commit tout-à-fait ordinaire ayant pour parent la révision courante. Elle sera référencée par une étiquette fonctionnant pratiquement comme une branche mais dans un espace dédié et qui permet surtout de savoir facilement quelles sont les révisions qui sont bien des remisages, et de les compter.

C'est intéressant parce que si, dans cet état, tu fais d'autres modifications, tu peux également les remiser sans avoir à dépiler les premières d'abord. En ce sens, cela fonctionne comme une pile mais en réalité, c'est bien le même mécanisme (branches et révisions successives se référant chacune à la précédente) qui permet de le faire. La man page indique toutefois que la commande s'appuie sur le reflog pour remonter la pile mais chaque objet a malgré tout une double parenté : l'empilement précédent et une référence permanente à l'objet de départ qui, lui, ne fait pas partie de la pile de stash. Mais tu n'es fort heureusement pas obligé de retenir tout ça.

Ça veut dire aussi que Git crée des objets à cette occasion, même s'ils sont censés être temporaires. Du coup, rien ne nous empêche de faire un checkout dessus, d'y ajouter de vraies révisions, etc. surtout si on ne sait pas exactement ce que l'on fait. Évidemment, on n'est jamais censé se retrouver dans cet état mais si ça arrive, le système est suffisamment bien conçu en lui-même pour que ce ne soit pas un problème. Toutes ces ressources sont gérées de la même façon que d'ordinaire et le dépôt ne peut jamais se corrompre.

Je viens de faire les 4 git stash

Euh… comment ça, « tu viens de les faire » ?

et par contre j'ai l'impression d'avoir perdu des données , dont des methodes pour faire des requetes sql sur mes objets

Pas de panique non plus. On a mis des tags partout sur les anciennes révisions, donc on peut retrouver ce qui a été commité. Si tes modifs étaient remisées avec stash, alors elles y sont toujours. Et si tu as vidé la pile de git stash cet après-midi, on pourra essayer de la rechercher dans le reflog.

Peux-tu nous faire une nouvelle copie d'écran du graphe tel que rendu par gitk, comme celui que tu nous présentes dans ton premier commentaire ?

Tu peux faire à nouveau :

Code Shell :

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

git stash list

… puis :

Code Shell :

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

git reflog stash

… pour voir s'il y a quelque chose à récupérer, et nous donner ici le résultat de ces commandes ?

Ensuite, essaie successivement :

Code Shell :

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

1
2
3
4
5
git diff master master20180418
git diff master dev20180418
git diff master development20180418
git diff master commandeTest20180418
git diff master featExceptionTwig20180418

Les lignes vertes correspondent à ce qui se trouve dans les anciennes révisions que l'on a marqué mais qui ne sont plus dans l'état actuel de master. C'est aussi normal qu'il y ait pas mal de lignes rouges (elles correspondent à ce qui n'existait pas encore à l'époque et que tu as rajouté depuis).

On s'intéresse aux lignes vertes. La plupart d'entre elles va correspondre à du contenu inutile ou obsolète, mais il est possible que tu y retrouves ce qui t'intéresse.

[Wilhem31]

Très bien , j’espère qu'à force je vais commencer a m'habituer et à comprendre le mécanisme !

Euh… comment ça, « tu viens de les faire » ?

En fait au moment ou j'écrivais le post je venais juste de faire les commandes c'est tout

Concernant le graph voila ce que ça donne :



Bon je modifie ce post car je dis n'importe quoi , concernant les git diff ils ne sont passé que pour:

git diff master dev20180418 :

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
diff --git a/.gitignore b/.gitignore
index d4858ba..1839309 100644
--- a/.gitignore
+++ b/.gitignore
@@ -7,7 +7,6 @@
 /var/cache/*
 !var/cache/.gitkeep
 !/var/logs
-.idea/
 /var/logs/*
 !var/logs/.gitkeep
 !/var/sessions
diff --git a/app/DoctrineMigrations/Version20180418091802.php b/app/DoctrineMigrations/Version20180418091802.php
deleted file mode 100644
index de9eef4..0000000
--- a/app/DoctrineMigrations/Version20180418091802.php
+++ /dev/null
@@ -1,34 +0,0 @@
-<?php
-
-namespace Application\Migrations;
-
:

git diff master featExceptionTwig20180418 :

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
diff --git a/.gitignore b/.gitignore
index d4858ba..2f75ca1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -7,7 +7,6 @@
 /var/cache/*
 !var/cache/.gitkeep
 !/var/logs
-.idea/
 /var/logs/*
 !var/logs/.gitkeep
 !/var/sessions
@@ -16,4 +15,3 @@
 !var/SymfonyRequirements.php
 /vendor/
 /web/bundles/
-.idea/
diff --git a/app/DoctrineMigrations/Version20180418091802.php b/app/DoctrineMigrations/Version20180418091802.php
deleted file mode 100644
index de9eef4..0000000
--- a/app/DoctrineMigrations/Version20180418091802.php
+++ /dev/null
:

git diff master commandeTest20180418:

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
diff --git a/.gitignore b/.gitignore
index d4858ba..2f75ca1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -7,7 +7,6 @@
 /var/cache/*
 !var/cache/.gitkeep
 !/var/logs
-.idea/
 /var/logs/*
 !var/logs/.gitkeep
 !/var/sessions
@@ -16,4 +15,3 @@
 !var/SymfonyRequirements.php
 /vendor/
 /web/bundles/
-.idea/
diff --git a/.idea/inspectionProfiles/Project_Default.xml b/.idea/inspectionProfiles/Project_Default.xml
new file mode 100644
index 0000000..fc5269c
--- /dev/null
+++ b/.idea/inspectionProfiles/Project_Default.xml
:

Pour development et master j'ai :
fatal: ambiguous argument 'development20180418': unknown revision or path not in the working tree.

Et du coup aucune trace des fichiers qui m'interesse ...

[Obsidian]

Très bien , j’espère qu'à force je vais commencer a m'habituer et à comprendre le mécanisme !
Concernant le graph voila ce que ça donne :

Bien. La bonne nouvelle, c'est que ton commit orphelin n'en était pas un. C'est juste que son lien de parenté était tracé en gris et recouvert par un autre. Donc, ça rentre dans la normale de ce côté-là.

Bon je modifie ce post car je dis n'importe quoi , concernant les git diff ils ne sont passé que pour…

Ok, visiblement rien d'important là non plus. On n'y voit que les quelques lignes de configuration que tu as rajoutées depuis.

Pour development et master j'ai :
fatal: ambiguous argument 'development20180418': unknown revision or path not in the working tree.

C'est normal : pour une raison ou une autre, tu n'as pas créé le tag « development20180418 » avec les autres. Ce n'est pas très important non plus. Apparemment, la branche « development » est restée là où elle était. Donc tu peux refaire :

Code Shell :

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

1
2
git tag development20180418 development
git diff master development20180418

… sinon tu fais directement :

Code Shell :

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

git diff master development

Au passage, peux-tu nous indiquer exactement la différence entre les branches dev et development, et nous dire si elles doivent toutes les deux repartir de la dernière version de master à ce jour ?

Reste à examiner ce que tu as remisé et jamais rétabli. Fais un :

Code Shell :

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

git stash list

Ensuite, il y a plusieurs manières d'aller remonter efficacement l'historique mais comme on n'a pas envie de s'embêter encore plus à ce stade, tape directement :

Code Shell :

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

1
2
3
4
5
6
git show stash@{0}
git show stash@{1}
git show stash@{2}
git show stash@{3}
git show stash@{4}
…

… sachant que ce faisant, tes modifications apparaîtront dans l'ordre chronologique inverse (stash@{0} est l'empilement le plus récent).

[Wilhem31]

En fait la branch development n'a pas grand interet , je l'avais juste crée quand je pensais que ma branch dev était en erreur derrière mais en soi je n'ai besoin de faire repartir que la dev.

Pour les git stash j'ai :

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 show stash@{0}
commit 44d150e77960b01de54f302d9a57426f6daab512
Merge: 3da7884 d2ba7d3
Author: xxxxxxx
Date:   Tue Apr 17 10:19:34 2018 +0200

    WIP on dev: 3da7884 bug idea

diff --cc .idea/workspace.xml
index bd1f080,bd1f080..2f1a9de
--- a/.idea/workspace.xml
+++ b/.idea/workspace.xml
@@@ -33,10 -33,10 +33,72 @@@
              <state relative-caret-position="442">
                <caret line="51" column="0" lean-forward="false" selection-start-line="51" selection-start-column="0" selection-end-line="51" selection-end-column="0" />
                <folding>
--                <marker date="1523873921797" expanded="false" signature="2630:2641" ph="/admin/" />
--                <marker date="1523873921797" expanded="false" signature="3537:3562" ph="admin/User-form" />
--                <marker date="1523873921797" expanded="false" signature="8725:8736" ph="/admin/" />
:

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
$ git show stash@{1}
commit ff4c4c960a304d0cffc66433ce98f4958ccee397
Merge: 44e68a7 ed29872
Author: xxxxxxxx
Date:   Tue Apr 17 09:34:10 2018 +0200

    WIP on master: 44e68a7 merge dev

diff --cc .idea/workspace.xml
index 0f5f83b,0f5f83b..791f793
--- a/.idea/workspace.xml
+++ b/.idea/workspace.xml
@@@ -116,7 -116,7 +116,7 @@@
            </provider>
          </entry>
        </file>
--      <file leaf-file-name="DefaultController.php" pinned="false" current-in-tab="false">
++      <file leaf-file-name="DefaultController.php" pinned="false" current-in-tab="true">
          <entry file="file://$PROJECT_DIR$/src/AppBundle/Controller/DefaultController.php">
            <provider selected="true" editor-type-id="text-editor">
              <state relative-caret-position="476">
:

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
$ git show stash@{2}
commit bddfdb9e10d080977449e3d8cb44a2a38d86989f
Merge: 098f2cc 50672cf
Author: xxxxxxx
Date:   Wed Feb 28 11:57:23 2018 +0100

    WIP on master: 098f2cc erreur

diff --cc .idea/workspace.xml
index 2705029,2705029..10ec960
--- a/.idea/workspace.xml
+++ b/.idea/workspace.xml
@@@ -24,7 -24,7 +24,7 @@@
    <component name="ExecutionTargetManager" SELECTED_TARGET="default_target" />
    <component name="FileEditorManager">
      <leaf SIDE_TABS_SIZE_LIMIT_KEY="300">
--      <file leaf-file-name="AdminController.php" pinned="false" current-in-tab="false">
++      <file leaf-file-name="AdminController.php" pinned="false" current-in-tab="true">
          <entry file="file://$PROJECT_DIR$/src/AppBundle/Controller/AdminController.php">
            <provider selected="true" editor-type-id="text-editor">
              <state relative-caret-position="153">
:

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
$ git show stash@{3}
commit 4adc670ac41b93e6d868f73ef84966495c0a6062
Merge: a783fac 5b65ffc
Author: xxxxxxxx
Date:   Wed Feb 28 11:54:37 2018 +0100

    WIP on master: a783fac  Bug cache

diff --cc .idea/workspace.xml
index 821a4c6,821a4c6..f348bcc
--- a/.idea/workspace.xml
+++ b/.idea/workspace.xml
@@@ -27,11 -27,11 +27,21 @@@
        <file leaf-file-name="AdminController.php" pinned="false" current-in-tab="false">
          <entry file="file://$PROJECT_DIR$/src/AppBundle/Controller/AdminController.php">
            <provider selected="true" editor-type-id="text-editor">
--            <state relative-caret-position="-68">
--              <caret line="32" column="24" lean-forward="false" selection-start-line="32" selection-start-column="24" selection-end-line="32" selection-end-column="24" />
++            <state relative-caret-position="153">
++              <caret line="32" column="40" lean-forward="true" selection-start:

Du coup, j'ai l'impression qu'il se ressemble assez mais que faut il faire avec ça ? A l'heure actuelle j'ai l'air d'avoir un repo assez propre , j'ai pas rencontré de problème .

[Obsidian]

Bonjour,

Attention : ton nom et ton e-mail apparaissent en clair dans le champ Author en tête de chaque commit. J'ai édité ton commentaire pour les masquer dans chacun de tes extraits.

Ce que tu vois en saisissant ces commande est exactement le même type de contenu que celui que tu obtiendrais en visualisant un commit ordinaire. Donc, des méta-informations en tête de compte-rendu, et le résultat de la commande diff qui te présente, en fait, les modifications proprement dites. Les lignes « --- » et « +++ » correspondent aux anciens et nouveaux fichiers (donc en général les mêmes sauf en cas de suppression ou de renommage). Les lignes « - » et « + » correspondent aux lignes supprimées et ajoutées (donc une ligne « - » suivie d'une ligne « + » correspond en fait à une ligne modifiée) et les lignes sans préfixe sont des lignes de contexte, c'est-à-dire l'entourage proche de chaque modification pour savoir où on est mais auxquelles on ne touche pas.

Donc, on voit ici que tes quatre remisage ne concernent à chaque fois que le fichier « .idea/workspace.xml » et il me semble que tu cherches à t'en débarrasser depuis le départ. Si c'est le cas tu peux effacer tes remisages en faisant :

Code Shell :

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

git stash drop

… quatre fois de suite (un pour chaque remisage).

Ensuite, pour les choses que tu penses avoir perdu, à ce stade, il n'y a que deux possibilités : soit elles ont vraiment été écrasées (possible mais peu probable étant donné l'historique de tes commandes) et elles seraient alors perdues, soit elles ont été commitées à un moment où un autre (quitte à revenir en arrière, à annuler des changements, à les remplacer par d'autres choses encore, etc.) et dans ce cas, elles sont quelque part dans ton graphe. Reste à savoir où.

Si tes méthodes ORM sont censées se trouver dans un fichier bien identifié, tu peux essayer de remonter toute une branche en ne demandant que les modifications portées à ce fichier en particulier. Par exemple :

Code Shell :

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

git log --patch commandeTest..master tonfichier

… et vois si tu arrives à retrouver quelque chose d'intéressant.

[Wilhem31]

Bonjour,

J'ai donc fait la commande git stash drop comme prévu.
J'ai vérifié et je pense avoir tout ce qu'il faut finalement, donc à voir par la suite si j'ai des erreurs mais ça a l'air pas mal.

Du coup , j'ai aussi mes branches dev et master qui ont l'air d'être reparties correctement, je pense qu'on est bon, là !

[Obsidian]

Bonjour,

J'ai donc fait la commande git stash drop comme prévu.

Ok, mais le faire une fois ne supprime que le dernier remisage en date. Fais un git stash list pour voir s'il en reste.

J'ai vérifié et je pense avoir tout ce qu'il faut finalement, donc à voir par la suite si j'ai des erreurs mais ça a l'air pas mal.

Bien. Mais effectivement, malgré tout, s'il te manque des choses et que cela est avéré, il serait intéressant d'essayer de les retrouver car autrement, si tu te contentes de les réécrire (ce qui est tout-à-fait concevable), cela voudrait dire que tu aurais perdu du travail à cause de ton logiciel de versioning (alors qu'il est censé garantir le contraire) et que tu n'as pas pu lui faire faire ce que tu souhaitais.

Autre chose : si des erreurs finissent par se produire, tu pourras aussi utiliser git bisect pour cibler facilement le moment du changement. Mais il est préférable d'apprendre à maîtriser le reste du logiciel d'abord.

Du coup , j'ai aussi mes branches dev et master qui ont l'air d'être reparties correctement, je pense qu'on est bon, là !

Tu pourras aussi effacer la référence à la branche « development » avec git branch -d development si tu es certain de ne plus en avoir besoin. C'est mieux si tu y mets un tag quand même pour pouvoir changer d'avis rapidement.

[Wilhem31]

Bonjour,

Très bien, j'ai bien une list stash qui est vide.

La référence a la branch development à aussi été effacé.

Si tu as d'autres conseils pour la suite je suis preneur, sinon vraiment un gros merci pour la rapidité de tes réponses et l'aide apporté !

[Obsidian]

Si tu as d'autres conseils pour la suite je suis preneur, sinon vraiment un gros merci pour la rapidité de tes réponses et l'aide apporté !

Avec plaisir.
Si tu n'as encore rien commité depuis, je te conseille de mettre un tag sur la révision courante de master, histoire de bien se souvenir à quel moment ton dépôt est « revenu à la normale » et pour que l'on puisse s'y référer rapidement dans ce fil si jamais tu découvres de nouvelles anomalies dans un futur proche.

À part cela, je t'enjoins à essayer d'appréhender le fonctionnement exact des objets Git, de l'index et des reflogs. Comme on l'a dit plus haut, lorsque ces choses-là sont au clair, tout le reste en découle de façon naturelle.

Bon courage.