Repo git en pagaille..

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 :

Pièce jointe 370906

Un sacré merdier que je n'arrive plus à comprendre, j'ai l'impression que ma branche dev est la master sont la même 8O 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...

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.

Citation:

---

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.

Citation:

---

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.

Citation:

---

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.

Citation:

---

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.

Citation:

---

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.

Concernant les history ca donne a peu pres ca :

Code:

---

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 ...

Citation:

---

Envoyé par Wilhem31

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.

Citation:

---

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.

Citation:

---

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).

Citation:

---

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.

Citation:

---

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:

---

git status

---

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

Code:

---

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:

---

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:

---

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:

---

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.

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

Bonjour,

Citation:

---

Envoyé par 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!

---

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).

Citation:

---

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.

Citation:

---

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 ?

Citation:

---

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.

Citation:

---

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).

Citation:

---

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:

---

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:

---

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:

---

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.

Citation:

---

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 ?

Citation:

---

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 8O

Citation:

---

Envoyé par Wilhem31

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.

Citation:

---

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.

Citation:

---

Je viens de faire les 4 git stash

---

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

Citation:

---

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

---

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:

---

git stash list

---

… puis :

Code:

---

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:

---

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.

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

Citation:

---

Envoyé par Obsidian

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 :

Pièce jointe 371333

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:

---

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:

---

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:

---

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 ...

Citation:

---

Envoyé par Wilhem31

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à.

Citation:

---

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.

Citation:

---

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:

---

1 2	git tag development20180418 development git diff master development20180418

---

… sinon tu fais directement :

Code:

---

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:

---

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:

---

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).

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:

---

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:

---

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:

---

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:

---

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 .

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:

---

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:

---

git log --patch commandeTest..master tonfichier

---

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

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à !

Citation:

---

Envoyé par Wilhem31

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.

Citation:

---

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.

Citation:

---

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.

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é !

Citation:

---

Envoyé par Wilhem31

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.