Git : comment merger une arborescence de fichiers ? (pas leur contenu).
Bonjour
Je voudrais merger une raborescence de fichier sous git, pas leur contenu, mais juste 2 arborescences.
J'ai cloné la branche de mon collègue : BrancheA
BrancheA
RepProjet
|--Collègue_Fichier1.v01
|--Collègue_Fichier2.v01
Lui travaille de son côté et obtient après commit de ses modifs sur la BrancheA
BrancheA
RepProjet
|--Collègue_Fichier1.v01
|--Collègue_Fichier2.v02 (new)
|--Collègue_Fichier3.v01 (new)
Moi de mon côté je travaille et ajoute des fichiers sans modifier les siens.
BrancheA (git clonée)
RepProjet
|--Collègue_Fichier1.v01
|--Collègue_Fichier2.v01
Et après ajout de mes modifs j'ai :
BrancheA
RepProjet
|--Collègue_Fichier1.v01
|--Collègue_Fichier2.v01
|--Mon_Fichier1.v01 (new)
|--Mon_Fichier2.v01 (new)
Comment merger nos modifs, quels sont les commandes à faire pour obtenir après nos commits respectifs :
BrancheA
RepProjet
|--Collègue_Fichier1.v01
|--Collègue_Fichier2.v02 (new)
|--Collègue_Fichier3.v01 (new)
|--Mon_Fichier1.v01 (new)
|--Mon_Fichier2.v01 (new)
Je veux merger l'arborescence et éventuellement des repertores, en aucun cas le contenu des fichiers.
Comment procéder ?
PAr avance merci pr vos tuyaux.
E.
# AMHA ca va etre compliqué
Posté par NeoX . Évalué à 4.
ca va etre compliqué
car c'est justement le principe de git de refusionner les dossiers et les fichiers d'un projet
car c'est justement le contenu du fichier qui est analysé pour savoir ce qui a changé.
donc si ton collegue ne touche qu'à ces fichiers, et toi au tiens,
tu fais les push qui vont bien et tu vas remettre TES nouveaux fichiers sur le serveur,
ton collegue les recuperes au prochain pull, mais ne touche pas les tiens,
[^] # Re: AMHA ca va etre compliqué
Posté par FueL . Évalué à 1.
Ca n'arrange pas mes affaires. Prtant il me semble que c'est possible au travers de ce que j'ai pu lire, mais peut être pas les options/utilisations les plus courantes de git.
[^] # Re: AMHA ca va etre compliqué
Posté par NeoX . Évalué à 3. Dernière modification le 23 janvier 2017 à 12:45.
en gros tu veux savoir qu'un fichier existe dans ce dossier, mais ne pas recuperer le fichier ?
à ce moment là, je ferais une branche par utilisateur, et toi tu ne travailles qu'avec le projet global + tabranche
# Conflits de merge ?
Posté par Obsidian . É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.
[^] # Re: Conflits de merge ?
Posté par FueL . Évalué à 2.
Bonjour
Mon besoin,
c'est à la fois récupérer les fichiers de mon collègue pour pouvoir les utiliser, et que mon collègue puisse faire la même chose avec les miens.
SAchant que :
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).
En tout cas merci pr tes réponses je vais voir comment je peux m'en sortir avec vos indications.
[^] # Re: Conflits de merge ?
Posté par Obsidian . É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.
[^] # Re: Conflits de merge ?
Posté par FueL . Évalué à 2.
Je vais regarder ça, et essayer de me familiariser avec git.
Merci beaucoup pr ta réponse.
[^] # Re: Conflits de merge ?
Posté par Obsidian . Évalué à 2.
N'hésite pas à venir redemander de l'aide si tu n'y arrives pas.
Mais d'ici là, essaie de faire « git log --patch » sur ta propre branche avant de la pousser. Cela te permettra de voir clairement quels sont les changements enregistrés par git et qui seront donc appliqués tels quels par le dépôt sur lequel tu les enverras ou qui décidera de les rapatrier lui-même.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.