1 - encore une fois on ne merge pas les contenus des fichiers
2 - on s'arrange lui et moi pour ne pas avoir de conflit dans les noms de nos fichiers (chacun des fichiers est prefixé par nos initiales).
Dans ce cas, c'est bel et bien un merge ordinaire. Il n'y aura jamais de fusion de fichiers imposée si vous vous arrangez déjà pour ne jamais travailler sur les mêmes (et si pour une raison ou une autre, tu t'y retrouvais confronté quand même, c'est qu'il se serait passé quelque chose en amont qui nécessiterait une décision de ta part pour être résolue).
Donc, tu fais tes modifs de ton côté, tu les commites en local avec « git commit », tu pousses tes propres modifs avec « git push » et tu récupères celles de ton collègue avec « git pull ». C'est la manière habituelle de travailler.
Il faut savoir qu'avec Git, comme avec d'autres logiciels de versioning, un « git pull » est équivalent à un « git fetch » suivi d'un « git merge » de la branche distante avec son homologue locale. Une branche est formée par la lignée de ses commits successifs, chacun faisant référence au précédent, et chaque commit décrit les changements apportés à la branche par rapport à l'état précédent.
C'est donc bien l'idée : si ton collègue travaille sur des fichiers A, B et C et que tu travailles sur des fichiers X, Y, et Z, alors son commit décrira quelque chose comme « +A; +B; +C; » et le tien « +X; +Y; +Z ». Fusionner les branches importera ses propres commits dans ton dépôt, ce qui y appliquera ses modifications, dont les effets concerneront des fichiers indépendants de ceux sur lesquels tu travailles.
En résumé : tu peux très bien fusionner une branche sans avoir à fusionner de fichiers.
[^] # Re: Conflits de merge ?
Posté par Obsidian . En réponse au message Git : comment merger une arborescence de fichiers ? (pas leur contenu). Évalué à 3.
Bonjour,
Dans ce cas, c'est bel et bien un merge ordinaire. Il n'y aura jamais de fusion de fichiers imposée si vous vous arrangez déjà pour ne jamais travailler sur les mêmes (et si pour une raison ou une autre, tu t'y retrouvais confronté quand même, c'est qu'il se serait passé quelque chose en amont qui nécessiterait une décision de ta part pour être résolue).
Donc, tu fais tes modifs de ton côté, tu les commites en local avec « git commit », tu pousses tes propres modifs avec « git push » et tu récupères celles de ton collègue avec « git pull ». C'est la manière habituelle de travailler.
Il faut savoir qu'avec Git, comme avec d'autres logiciels de versioning, un « git pull » est équivalent à un « git fetch » suivi d'un « git merge » de la branche distante avec son homologue locale. Une branche est formée par la lignée de ses commits successifs, chacun faisant référence au précédent, et chaque commit décrit les changements apportés à la branche par rapport à l'état précédent.
C'est donc bien l'idée : si ton collègue travaille sur des fichiers A, B et C et que tu travailles sur des fichiers X, Y, et Z, alors son commit décrira quelque chose comme « +A; +B; +C; » et le tien « +X; +Y; +Z ». Fusionner les branches importera ses propres commits dans ton dépôt, ce qui y appliquera ses modifications, dont les effets concerneront des fichiers indépendants de ceux sur lesquels tu travailles.
En résumé : tu peux très bien fusionner une branche sans avoir à fusionner de fichiers.