Ça veut bien dire que tu veux synchroniser les branches et obtenir — dans ton dépôt — les fichiers de ton collègue et vice-versa, n'est-ce pas ? Dans ce cas, il s'agit d'un merge ordinaire.
Plus précisément, ici, tu vas d'abord faire un « commit » en local, et git verra que les seuls changements apportés à ton dépôt par rapport à l'état précédent est l'ajout de tes deux fichiers « Mon_Fichier1 et 2 ». Et c'est exactement cela qui sera enregistré dans le commit. Quand tu vas faire « git push » ensuite, c'est ce commit-là qui sera envoyé et qui appliquera les mêmes changements au dépôt distant. Donc, même si ton collège fait la même chose de son côté avec les siens, vous vous retrouverez avec la somme des deux changements et aucun de vous n'aura marché sur les pieds de l'autre.
Sinon, prend le problème à l'envers :
– Soit tu veux récupérer uniquement les « noms » de fichiers à leur place dans le dépôt, sur le FS. Dans ce cas, que doit-il se passer si tu en ouvres un ?
— Soit tu veux justement récupérer le contenu de la branche « distante » puisque ces fichiers appartiennent à ton collègue → merge ordinaire, là aussi ;
— Si tu veux simplement afficher les fichiers de ton collègue, que doit-il se passer si celui-ci a eu la bonne idée de créer chez lui un fichier qui existait déjà chez toi sous le même nom ? La question n'est pas anodine car elle va nous permettre de savoir ce que tu as réellement en tête et, de là, t'orienter correctement. Peut-être même est-ce pour cela que tu as cette idée : justement pour savoir si un nom de fichier est libre ou déjà réservé...
— Vous souhaitez travailler chacun de votre côté et exporter à la fin uniquement les choses qui vous intéressent vers un dépôt commun officiel qui, lui, doit être synchrone : voir la solution de NeoX ;
— Tu souhaites avoir une « vue » sur le dépôt de ton collègue (et réciproquement) sans avoir à l'importer directement au sein du tien ? C'est le principe de la branche « remote ». Celle-ci est répliquée en local quand tu fais « git fetch » (et notamment, tous les objets associés sont rappatriés) mais reste distincte, et reflète l'état de la branche distante même si celle-ci est reconstruite. Tu peux ensuite y associer une vraie branche locale sur laquelle tu peux éventuellement travailler et fusionner l'avancée de la branche distante. C'est le cas de « master » (local) et « origin/master » (remote) quand tu utilises le modèle par défaut. Si tu veux jeter un œil à ce qui se passe à côté, tu peux faire un checkout sur la branche remote et revenir ensuite sur la tienne.
# Conflits de merge ?
Posté par Obsidian . En réponse au message Git : comment merger une arborescence de fichiers ? (pas leur contenu). Évalué à 3.
Salut,
J'ai moi aussi un peu de mal à voir où tu veux en venir. Je lis :
Ça veut bien dire que tu veux synchroniser les branches et obtenir — dans ton dépôt — les fichiers de ton collègue et vice-versa, n'est-ce pas ? Dans ce cas, il s'agit d'un merge ordinaire.
Plus précisément, ici, tu vas d'abord faire un « commit » en local, et git verra que les seuls changements apportés à ton dépôt par rapport à l'état précédent est l'ajout de tes deux fichiers « Mon_Fichier1 et 2 ». Et c'est exactement cela qui sera enregistré dans le commit. Quand tu vas faire « git push » ensuite, c'est ce commit-là qui sera envoyé et qui appliquera les mêmes changements au dépôt distant. Donc, même si ton collège fait la même chose de son côté avec les siens, vous vous retrouverez avec la somme des deux changements et aucun de vous n'aura marché sur les pieds de l'autre.
Sinon, prend le problème à l'envers :
– Soit tu veux récupérer uniquement les « noms » de fichiers à leur place dans le dépôt, sur le FS. Dans ce cas, que doit-il se passer si tu en ouvres un ?
— Soit tu veux justement récupérer le contenu de la branche « distante » puisque ces fichiers appartiennent à ton collègue → merge ordinaire, là aussi ;
— Si tu veux simplement afficher les fichiers de ton collègue, que doit-il se passer si celui-ci a eu la bonne idée de créer chez lui un fichier qui existait déjà chez toi sous le même nom ? La question n'est pas anodine car elle va nous permettre de savoir ce que tu as réellement en tête et, de là, t'orienter correctement. Peut-être même est-ce pour cela que tu as cette idée : justement pour savoir si un nom de fichier est libre ou déjà réservé...
— Vous souhaitez travailler chacun de votre côté et exporter à la fin uniquement les choses qui vous intéressent vers un dépôt commun officiel qui, lui, doit être synchrone : voir la solution de NeoX ;
— Tu souhaites avoir une « vue » sur le dépôt de ton collègue (et réciproquement) sans avoir à l'importer directement au sein du tien ? C'est le principe de la branche « remote ». Celle-ci est répliquée en local quand tu fais « git fetch » (et notamment, tous les objets associés sont rappatriés) mais reste distincte, et reflète l'état de la branche distante même si celle-ci est reconstruite. Tu peux ensuite y associer une vraie branche locale sur laquelle tu peux éventuellement travailler et fusionner l'avancée de la branche distante. C'est le cas de « master » (local) et « origin/master » (remote) quand tu utilises le modèle par défaut. Si tu veux jeter un œil à ce qui se passe à côté, tu peux faire un checkout sur la branche remote et revenir ensuite sur la tienne.