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