30

roll
avatarAll right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

31

32

Hello ici,

Folco (./4) :
...
Pour la seconde question, j'avais copié mais pas collé le lien qui se voulait illustratif ; le voici : https://github.com/Folcogh/Packinov3/commit/21de390d1095d1058e84778ec8ed335713dbbe87
Quand j'ai voulu faire un "Commit to master" avec Tortoise Git, il m'a proposé ce commit d'office, sans que je touche à rien. Ou plutôt, sans que je comprenne à quoi j'aurais pas dû toucher grin

Une explication du phénomène ?

Pour compléter l'explication de Zeph (./5), on peut essayer de décomposer les informations affichées dans le Github afin de savoir ce qu'il s'est passé:

2018_02_27_01h51_22.png

Primo, on y voit d'abord dans le message du commit une référence à un merge qui correspond à l'explication de Zeph (les deux états au moment du pull étaient différents et non des états descendants l'un de l'autre, du coup Git propose de faire un commit de merge). Si les deux états étaient des descendants l'un de l'autre, le merge des deux aurait été très simple à faire: il serait revenu à déplacer la branche actuelle au niveau de l'état le plus récent des deux. Ce qui revient à un "fast-forward" (mais ceci... est une autre histoire, la précision est pour les curieux).

Ensuite, on y voit une ligne qui parle de conflit sur le fichier Packinov3.pro. Ces lignes sont mises par défaut dans le message du commit pour garder une trace des conflits qui ont été marqués comme résolus lors du commit de merge. On peut bien évidemment changer le message si on en a décidé ainsi mais bon.
Merge branch 'master' of https://github.com/Folcogh/Packinov3

# Conflicts:
#	Packinov3.pro

Comme il s'agit d'un fichier binaire, il est fort probable que la différence entre les deux versions ne soient pas très parlante dans un diff texte, mais cela montre que tu as du résoudre le conflit soit en choisissant de garder la version locale (Tortoise Git -> Resolve... -> Right Click sur le fichier-> Resolve conflict using 'mine') ou la version du fichier distant (Tortoise Git -> Resolve... -> Right Click sur le fichier-> Resolve conflict using 'theirs') ou bien encore que tu as ouvert et modifié le fichier alors que l'état du repo git était en attente de fin de merge.
Pour la résolution de conflit binaire, on ne s'occupera pas de prendre une partie de l'un et une partie de l'autre comme on pourrait le faire sur des fichiers textes, du coup on n'a que ces trois choix là: garder l'actuelle, prendre la distante, ou changer en ne prenant aucun des deux ^^.

On peut aussi voir que le fichier .gitignore a été supprimé. Il arrive que les logiciels tournant autour de git (comme les IDE) propose automatiquement de "stager" les suppressions/ajouts de fichiers. (pour rappel: stager une modification == l'ajouter au prochain commit).
Cette suppression a eu lieu quand le repo git était en état MERGING donc en attente de finition de merge. C'est l'explication que cette modification se retrouve dans le commit de merge.


En résumé:
Je dirais que l'histoire décrite ici ressemble un peu à ça:
  • modifications à la maison non poussées (mais commitées)
  • modifications au travail commitées et poussées
  • rentrage maison
  • pull -> BIM conflits -> état MERGING en attente qu'on lui dise qu'on a résolu les conflits
  • on s'en fout un peu du message (je ne sais meme pas comment la tortue annonce cet état), on galère un peu à bidouiller/chercher pour retrouver un état stable
  • on finit par éditer le fichier et continuer notre vie comme si de rien n'était, on commit des choses (ici une autre version du fichier binaire et la suppression du .gitignore)
  • l'état du repo étant marqué comme résolu, la vie continue, on peut donc push et c'est reparti comme en 40.
avatar

33

Bon, ayant oublié de commiter vendredi soir au boulot, et ayant fait des modifs ce week-end à la maison, je suis un peu coincé. Du moins, j'ai relu vos précieux conseils, et j'y vois déjà bien plus clar que la dernière fois. smile

Donc j'ai essayé la méthode simple : stash de mes modifications à la maison, pour ne rien changer sur origin, et pop du stash au boulot, pour récupérer mes modifs du week-end.
Mais... cette pile magique, elle est uniquement valable pour le dépôt local, on ne peut pas la transférer sur le dépôt distant ??
En tout cas, je n'ai pas trouvé commetn faire ça sad

Sinon, tant pis, je créerai une branche, même si amha c'est un peu overkill pour quelques lignes de code.
A moins que l'outil soit tout simplement prévu pour ça : qu'on parle de 1 ligne ou de 100 klocs, la méthode propre est de créer une branche à intégrer ensuite.
C'est un "merge" qu'il faudra que je fasse, pour intégrer la branche à master ?

Merci d'avance. smile
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !

34

Tu peux pas juste commiter quand tu arrives au bureau, faire un update quand tu es chez toi, résoudre les éventuels conflits, et finalement commiter ce que tu as chez toi ? (ou dans l'autre sens si c'est possible)

35

le stash est local a la copie de travail oui.

36

+1 pen^2 ; si c'est de te retrouver avec un historique non linéaire qui te chagrine, tu peux toujours rebase au lieu de merge. D'ailleurs, pour récupérer des changements distants et replacer tes changements locaux (qui n'ont pas encore été poussés) par-dessus tu peux le faire en une seule commande : git pull --rebase origin master comme le disait Kevin en ./8
avatarAll right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

37

Merci ! Bon promis, ce soir je recreuse un coup ce truc de rebase et merge, parce que je sens bien que j'ai un truc qui coince à ce niveau sad

Merci encore ! top
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !