Est-il “leur” version de “git merge -s nôtre”?

Lors de la fusion de sujet, succursale "B" dans "Un" à l'aide de git merge, je reçois des conflits. Je sais que tous les conflits peuvent être résolus à l'aide de la version "B".

Je suis conscient de git merge -s ours. Mais ce que je veux, c'est quelque chose comme git merge -s theirs.

Pourquoi ne pas exister? Comment puis-je obtenir le même résultat après le conflit de fusion avec l'existant git commandes? (git checkout chaque désinstallé le fichier à partir de B)

Mise à JOUR: La "solution" de simplement les jeter quelque chose à partir d'Une branche (la fusion point de validation de la version B de l'arbre) n'est pas ce que je suis à la recherche d'.

  • Voir aussi cette réponse: stackoverflow.com/questions/928646/... - c'est trivial pour changer l'exemple utiliser la version B à la place de A.
  • Voir DONC réponse commande git pour faire une branche comme les autres pour tous les moyens possibles pour simuler git merge -s their.
  • Si vous n'êtes pas vraiment à la recherche d'un git merge -s theirs (qui peut être atteint facilement avec git merge -s ours et temporaire de la branche), depuis -s nôtre ignore complètement les changements de la fusion de la direction de...
  • faire le Git devs vraiment le trouver offensive de fournir theirs en plus de ours??? C'est un symptôme de l'un de haut niveau de l'ingénierie et de la conception des problèmes dans Git: incohérence.
  • Le problème ici n'est pas "git merge -s nôtre" être offensant, mais elle était contre-intuitif. Vous pouvez le voir dans le cas des OP question que si une telle fonctionnalité serait ajouté qu'il serait de l'utiliser par erreur, en ce qu'il veut réellement faire, c'est un "git merge -s récursive -X le leur". Il est courant de vouloir fusionner une autre branche primordial en conflit avec la version sur l'autre branche, mais complètement écraser la branche courante, avec une autre branche complètement à jeter le cours du change est vraiment un cas d'exception.
  • Tout le monde devrait vérifier l'OP "mise à jour" soigneusement que la question n'a rien à voir avec git merge -s ours.
  • Voir aussi: git merge stratégies
  • chaque fois que j'avais à fusionner dans ma vie, j'ai toujours voulu prendre le "leur" version
  • Bottom line: c'est git merge -X theirs
  • git merge -X le leur Ne fonctionne pas si vous avez des centaines de suppressions de fichier que vous essayez de fusionner avec une autre branche.

InformationsquelleAutor elmarco | 2008-10-06
  1. 918

    Ajouter le -X option pour theirs. Par exemple:

    git checkout branchA
git merge -X theirs branchB

    Tout de la fusion de la façon souhaitée.

    La seule chose que j'ai vu causer des problèmes si des fichiers ont été supprimés à partir de branchB. Ils apparaissent comme des conflits si quelque chose d'autre que git ne l'enlèvement.

    La solution est facile. Il suffit d'exécuter git rm avec le nom de tous les fichiers qui ont été supprimés:

    git rm {DELETED-FILE-NAME}

    Après cela, le -X theirs devrait fonctionner comme prévu.

    Bien sûr, de faire le retrait de l'implant avec la git rm commande d'empêcher les conflits de se produire en premier lieu.

    Note: Une forme longue est également possible. Pour l'utiliser, remplacer:

    -X theirs

    avec:

    --strategy-option=theirs
    • Voir la réponse ci-dessous pour une meilleure solution (Paul Pladijs) à la question d'origine.
    • Vaut la peine de noter que ce n'est pas la même que la "fusion de la stratégie theirs". -Xtheirs est la stratégie de option appliquée à récursive stratégie. Cela signifie que récursive stratégie sera toujours fusionner tout ce qu'il peut, et ne revenir à "leur" logique dans le cas de conflits. Alors que c'est ce dont on a besoin dans la plupart des cas, comme ci-dessus, ce n'est pas la même chose que "juste de prendre tout de la branche B est". Il ne le réel de fusion au lieu de toute façon.
    • Il travaille avec d'autres commandes. Je viens de faire un "git cherry-pick sha1 -X les leurs". Merci!
    • Cela ne fonctionne pas dans le cas de noms de fichiers
    • - Je exécuter git merge -X theirs branchB git rm --ignore-unmatch $(git diff branchB --name-only) La deuxième commande supprime tous les fichiers supprimés automatiquement.
    • C'est une terrible réponse, parce qu'elle semble correct, mais est en fait mal. "git merge -X leurs" ne pas faire ce que "git merge -s leur ferait". Il ne remplace pas la branche courante, avec le contenu de la fusion de la branche. Il préfère les "leurs" changements, mais seulement en cas de conflit. Par conséquent, la validation peut être tout à fait différent de "leur" branche. Ce n'est pas que l'affiche avait à l'esprit.
    • c'est seulement une terrible réponse, parce que la question est si terrible, que l'OP veut à l'opposé de git merge -X ours par opposition à l'opposé de git merge -s ours. Cette réponse doit refléter le fait que le question est en fait valide.
    • oui, vous avez raison. J'ai relu la question, et il est également pas très bon. Malheureusement, la cause de la confusion n'est pas la réponse et même pas la question. C'est le choix de conception de git auteurs de donner le même nom "la nôtre" à une fusion de la stratégie et de la possibilité de fusion de la stratégie récursive'. La confusion qui règne dans ce cas est pratiquement inévitable.
    • ce n'est pas le bon endroit pour poser une question, mais qui commande de NE "il suffit de prendre tout ce à partir de la branche B est"?
    • si cette solution n'est pas de la suite de la nécessité, peut-être quelque chose composé de plusieurs commandes git peut travailler, comme dans d'autres réponses ci-dessous.

    InformationsquelleAutor Alan W. Smith
  2. 196

    Une possible solution testée pour la fusion branchB dans nos extraits branchA:

    # in case branchA is not our current branch
git checkout branchA

# make merge commit but without conflicts!!
# the contents of 'ours' will be discarded later
git merge -s ours branchB    

# make temporary branch to merged commit
git branch branchTEMP         

# get contents of working tree and index to the one of branchB
git reset --hard branchB

# reset to our merged commit but 
# keep contents of working tree and index
git reset --soft branchTEMP

# change the contents of the merged commit
# with the contents of branchB
git commit --amend

# get rid off our temporary branch
git branch -D branchTEMP

# verify that the merge commit contains only contents of branchB
git diff HEAD branchB

    Pour automatiser, vous pouvez l'envelopper dans un script à l'aide branchA et branchB comme arguments.

    Cette solution préserve le premier et le deuxième parent de la fusion de commettre, comme vous pouvez attendre de git merge -s theirs branchB.

    • Q: Pourquoi avez-vous besoin branchTEMP? Ne pourriez-vous git reset --soft branchA?
    • En quelque sorte j'ai pensé la même chose, mais non. Notez que git reset --hard changements qui s'engagent branchA points.
    • Je vois. Vrai. Mais le tout est plus simple si vous venez de fusionner branchA en branchB. Il est facile pour effectuer une avance rapide et Un reset B, si vous le souhaitez. Le seul inconvénient est que ^ et ^^ serait annulée. J'aime Shyam la réponse de ici.
    • Je pense à l'aide de git reset --soft HEAD@{1} vous pouvez obtenir tout de même que la création d'une nouvelle branche. En utilisant le présent au lieu de git reset --soft branchTEMP, vous pouvez laisser les git branch branchTEMP et git branch -D branchTEMP
    • Le hard reset ne fonctionne pas pour moi, parce que je ne peux pas garder l'histoire sur ma branche.
    • désolé de poser une question stupide, mais pourquoi cette méthode est mieux la -xtheirs? quels sont les avantages/inconvénients
    • leurs n'affecte que conflit, si un morceau de la nôtre peut être appliqué correctement, il va passer au travers de la fusion résultante. Dans ce cas, comme illustré par la dernière commande, nous obtenons une fusion qui est parfaitement identique pour branchB, indépendamment de savoir si il y aurait eu des conflits ou pas.
    • à l'aide de réinitialisation ne fonctionne pas comme la fusion commit sera perdu; branchTEMP même si elle peut être évitée par le stockage de l'id de la fusion s'engager au lieu tmp=`git rev-parse HEAD` et puis en utilisant à la place de branchTEMP
    • ...ou encore mieux de regarder siegi de l' et thoutbeckers les réponses ci-dessous pour encore plus concis (et idiomatiques) des moyens d'atteindre cet objectif sans une temporaire de la branche
    • merci pour l'explication, donc en gros, faire un "leurs" permettrait de garder des nations unies en situation de conflit les changements et les fichiers résultant de la int code qui n'est pas identique à l'tiré de code.
    • la meilleure solution pour vous, mais avec 2 s'engage, pour terminer le travail, vous pouvez ajouter : git rebase --interactive --preserve-merges HEAD~2 et le résultat en seulement 1 commit
    • Cela a très bien fonctionné pour moi, merci 😀
    • vous venez de m'a sauvé heures (littéralement) la résolution 1300+ les fichiers un par un <3
    • C'est génial !!! A se taper la tête pour les fichiers manquants à partir d'autres de la branche depuis hier. Merci beaucoup.

    InformationsquelleAutor Paul Pladijs
  3. 84

    Les anciennes versions de git vous a permis d'utiliser le "leur" stratégie de fusion:

    git pull --strategy=theirs remote_branch

    Mais cela a depuis été supprimé, comme expliqué dans ce message par Junio Hamano (Git responsable). Comme indiqué dans le lien, au lieu de cela vous voulez faire cela:

    git fetch origin
git reset --hard origin

    Méfiez-vous, cependant, que ce est différente de celle d'une fusion réelle. Votre solution est probablement l'option que vous cherchez vraiment.

    • merci, je ne suis pas totalement satisfaire par ma réponse, mais cependant, il manquait la caisse d'autres fichiers dans le vieux. c'était bizarre, je l'ajoute à la caisse... à commit --amend ensuite.
    • Je ne comprends vraiment pas Junio Hamano est une explication. Comment est git reset --hard origin une solution pour leur style de fusion? Si je voulais fusionner BranchB en BranchA (comme dans Alan W. Smith réponse), comment pourrais-je le faire à l'aide de la reset méthode?
    • McMahon: Junio C Hamano point n'est pas git reset --hard fait “leur”style de fusion. Bien sûr, git reset --hard ne crée pas de fusion de commettre, ou tout s'engager pour cette question. Son point est que il ne faut pas utiliser une fusion pour remplacer celui que dans la TÊTE par quelque chose d'autre. Je ne suis pas forcément d'accord, cependant.
    • C'est une honte que le theirs a été supprimé parce que la justification était incomplète. Il n'a pas autorisé pour les cas où le code est bon, c'est juste que l'amont est maintenu sur un autre fondement philosophique, donc dans ce sens est "mauvais", donc on n'a envie à la fois de tenir à jour avec l'amont, mais dans le même temps conserver un bon code de 'bugs' [git & msysgit ont de ce de ce "conflit" en raison de leurs différentes cibles de la plate-forme philosophies]
    • Il manque aussi le cas d'utilisation je suis coincé maintenant, où je partage une branche avec quelqu'un d'autre et nous avons tous les deux sont arrivés à remonter les modifications (sur les différents fichiers) en même temps. Je tiens donc à neutraliser toutes les vieilles versions que j'ai en local et à l'utilisation de sa plus récente à la place. Il veut faire la même chose pour les fichiers que j'ai mis à jour. Il n'y a rien de "réinitialiser". Et la solution à la caisse chaque fichier n'est pas pratique quand il s ~20 fichiers.
    • Je ne comprends vraiment pas la philosophie. J'ai juste utilisé theirs parce que j'avais accidentellement modifié quelques fichiers dans les deux branches distinctes et a voulu ignorer les modifications de l'un sans avoir à le faire manuellement pour chaque fichier.
    • Si les fichiers sont différents, il n'y aura pas de conflits de fusion. Donc, vous devriez être en mesure de faire une simple opération de fusion pour obtenir ses changements. Ai-je raté quelque chose?
    • Je ne me souviens pas vraiment maintenant, depuis qu'il a été 3 (!) il y a des années, mais je pense que c'était parce qu'on nous a dit de partager une branche, qui était une idée stupide et très peu de défaites le but de git ramification.

    InformationsquelleAutor Pat Notz
  4. 60

    J'ai utilisé la réponse de Paul Pladijs depuis maintenant. J'ai trouvé, vous pouvez faire un "normal" de fusion, les conflits se produisent, de sorte que vous ne 

    git checkout --theirs <file>

    pour résoudre le conflit en utilisant la révision de l'autre branche. Si vous faites cela pour chaque fichier, vous avez le même comportement que vous attendez de 

    git merge <branch> -s theirs

    De toute façon, l'effort est plus que ce serait avec la fusion et de stratégie! (Cela a été testé avec git version 1.8.0)

    • ce serait génial si la liste de fichiers peuvent être récupérés. Par exemple, git ls-files --modified | xargs git add je voulais le faire pour ajouté sur les deux côtés de fusion :/
    • En fait git renvoie l'ajoutés sur les deux côtés de fichiers avec git ls-files --modified donc je suppose que c'est également une solution viable.
    • Merci pour l'ajout de cette trop. Le plus souvent il est nécessaire sur un fichier par fichier de base. Aussi, git status affiche "non fusionné les Chemins d'accès" au bas de l'écran. Pour obtenir la liste de problèmes non résolus chemins, j'ai utiliser cet alias: git config --global alias.unresolved '!git status --short|egrep "^([DAU])\1"'
    InformationsquelleAutor musicmatze
  5. 54

    Il n'est pas tout à fait clair que le résultat recherché est, il ya une certaine confusion au sujet de la "bonne" façon de le faire dans les réponses et de leurs commentaires. J'essaie de donner une vue d'ensemble et de voir l'une des trois options suivantes:

    Essayer de fusion et utilisez B pour les conflits

    C'est pas la "leur version pour git merge -s ours" mais "leur version pour git merge -X ours" (qui est court pour git merge -s recursive -X ours):

    git checkout branchA
# also uses -s recursive implicitly
git merge -X theirs branchB

    C'est ce que par exemple Alan W. Smith réponse n'.

    Utiliser le contenu de B seulement

    Cela crée une fusion de s'engager pour les deux branches, mais ignore toutes les modifications de branchA et ne conserve que le contenu de branchB.

    # Get the content you want to keep.
# If you want to keep branchB at the current commit, you can add --detached,
# else it will be advanced to the merge commit in the next step.
git checkout branchB

# Do the merge an keep current (our) content from branchB we just checked out.
git merge -s ours branchA

# Set branchA to current commit and check it out.
git checkout -B branchA

    Noter que la fusion s'engage premier parent, c'est maintenant que de branchB et seulement la deuxième est de branchA. C'est ce que par exemple Gandalf458 réponse n'.

    Utiliser le contenu à partir de B et de garder parent correcte afin

    C'est le réel "leur version pour git merge -s ours". Il a le même contenu que l'option avant (c'est à dire uniquement qu'à partir de branchB) mais l'ordre des parents est correct, c'est à dire le premier parent vient de branchA et la deuxième à partir de la branchB.

    git checkout branchA

# Do a merge commit. The content of this commit does not matter,
# so use a strategy that never fails.
# Note: This advances branchA.
git merge -s ours branchB

# Change working tree and index to desired content.
# --detach ensures branchB will not move when doing the reset in the next step.
git checkout --detach branchB

# Move HEAD to branchA without changing contents of working tree and index.
git reset --soft branchA

# 'attach' HEAD to branchA.
# This ensures branchA will move when doing 'commit --amend'.
git checkout branchA

# Change content of merge commit to current index (i.e. content of branchB).
git commit --amend -C HEAD

    C'est ce que Paul Pladijs réponse n' (sans avoir besoin temporaire de la branche).

    • Une version plus propre de l'option 3: git checkout branchA; git merge -s ours --no-commit branchB; git read-tree -um @ branchB; git commit
    • Alors que votre version est plus concis, il utilise également le faible, niveau de la plomberie") commande read-tree que la moyenne des utilisateurs de git peut pas être utilisé pour (au moins je ne suis pas 😉 ). Les solutions dans la réponse d'utiliser seulement le haut niveau ("porcelaine") la plupart des commandes git les utilisateurs devraient savoir. Je les préfère, mais je vous remercie pour votre version quand même!
    • Pouvez-vous expliquer la deuxième à la dernière étape (la caisse branchA)? Il me semble qu'il ne devrait pas y être.
    • cette étape est nécessaire. Si vous l'ignorer, vous obtiendrez la même livraison, mais vous n'auriez pas une direction de pointage à ce commit. Donc dès que vous passez à un autre commit/direction générale de la validation que vous avez fait avec la dernière commande (…commit --amend…) serait "perdu". J'ai l'intention d'ajouter un peu de graphique d'explications pour cette réponse dès que j'ai le temps de les faire... 😉
    InformationsquelleAutor siegi
  6. 20

    J'ai résolu mon problème en utilisant

    git checkout -m old
git checkout -b new B
git merge -s ours old
    • une succursale "B" de la "vieille branche"
    InformationsquelleAutor elmarco
  7. 14

    Si vous êtes sur la direction générale de la faire:

    git merge -s recursive -X theirs B

    Testé sur git version 1.7.8

    InformationsquelleAutor rafalmag
  8. 8

    Lors de la fusion de sujet, succursale "B" à "A" à l'aide de git merge, je reçois des conflits. I >connaître tous les conflits peuvent être résolus à l'aide de la version "B".

    Je suis conscient de git merge -s nôtre. Mais ce que je veux, c'est quelque chose comme git merge >-s de leur.

    Je suis en supposant que vous avez créé une branche de master et vous souhaitez fusionner en maître, ignorant tout de l'ancien maître. C'est exactement ce que je voulais faire quand je suis tombé sur ce post.

    Faire exactement ce que vous voulez faire, à l'Exception de fusion de l'un dans l'autre en premier. J'ai juste fait ça, et ça a très bien fonctionné.

    git checkout Branch
git merge master -s ours

    Puis, checkout master et de fusion de votre branche (il va aller bien maintenant):

    git checkout master
git merge Branch
    InformationsquelleAutor Gandalf458
  9. 6

    Pour vraiment bien faire une fusion qui prend seulement d'entrée de la direction générale, vous êtes la fusion que vous pouvez faire

    git merge --strategy=ours ref-to-be-merged

    git diff --binary ref-to-be-merged | git apply --reverse --index

    git commit --amend

    Il n'y aura pas de conflits dans n'importe quel scénario que je connais, vous n'avez pas à faire d'autres branches, et il agit comme une normale de fusion s'engager.

    Cela ne veut pas jouer gentil avec les submodules cependant.

    • Ce qui ne l'-R faire ici?
    • De cette façon, vous perdez de l'historique des fichiers "déménagé et changé". Suis-je le droit?
    • Le -R --inverse, j'ai mis à jour la réponse à celui qui sera plus auto-documentation.
    • Cela ne semble pas fonctionner si les fichiers que vous essayez de fusionner sont supprimés dans le service réceptif.
    InformationsquelleAutor thoutbeckers
  10. 5

    Voir Junio Hamano est largement cité répondre: si vous allez jeter commis de contenu, juste jeter la commet, ou en tout cas de le garder hors de la main de l'histoire. Pourquoi s'embêter à tout le monde dans l'avenir de la lecture des messages de validation de commits qui n'ont rien à offrir?

    Mais il y a parfois des exigences administratives, ou peut-être une autre raison. Pour les situations où vous avez vraiment d'enregistrement s'engage à ce que n'apportant rien, vous souhaitez:

    (edit: wow, j'ai réussi à obtenir cette erreur avant. Celui-ci fonctionne.)

    git update-ref HEAD $(
        git commit-tree -m 'completely superseding with branchB content' \
                        -p HEAD -p branchB    branchB:
)
git reset --hard
    InformationsquelleAutor jthill
  11. 3

    Pourquoi ne pas exister?

    Alors que je le mentionne dans "commande git pour la fabrication de branche en branche comme un autre" comment simuler git merge -s theirs, notez que Git 2.15 (T4 2017) est maintenant plus claire:

    La documentation pour " -X<option> " pour se confond était point de prêter à confusion
    écrit pour suggérer que "-s theirs" existe, ce qui n'est pas le cas.

    Voir s'engager c25d98b (25 septembre 2017) par Junio C Hamano (gitster).

    (Fusionnés par Junio C Hamano -- gitster -- dans s'engager 4da3e23 28 septembre 2017)

    de fusion-stratégies: éviter ce qui implique que "-s theirs" existe

    La description de -Xours option fusion a une incidente
    qui indique au lecteur que c'est très différent de -s ours,
    ce qui est correct, mais la description de -Xtheirs qui la suit
    négligemment dit "c'est le contraire de ours", en lui donnant un faux
    impression que les lecteurs ont aussi besoin d'être averti qu'il est très
    différent de -s theirs, qui en réalité n'existe même pas.

    -Xtheirs est un stratégie option appliquée à récursive de la stratégie. Cela signifie que récursive stratégie sera toujours fusionner tout ce qu'il peut, et ne revenir à "theirs" logique dans le cas de conflits.

    Que le débat de la pertinence ou non d'un theirs de fusion de la stratégie a été ramené récemment dans ce Sept. 2017 fil.

    Il reconnaît les plus âgés (2008) de threads

    En bref, la discussion précédente peut se résumer à "nous ne voulons pas '-s theirs' il encourage le mal de flux de travail".

    Il mentionne le nom d'alias:

    mtheirs = !sh -c 'git merge -s ours --no-commit $1 && git read-tree -m -u $1' -

    Yaroslav Halchenko essaie de défendre une fois de plus pour cette stratégie, mais Junio C. Hamano ajoute:

    La raison pour laquelle la nôtre et la leur n'est pas symétrique est parce que vous êtes vous et pas d'eux---le contrôle et la propriété de notre histoire et de leur histoire n'est pas symétrique.

    Une fois que vous décidez que leur histoire est la ligne principale, vous préférez vous voulez traiter votre ligne de développement que d'un côté de la branche et de faire une fusion dans cette direction, c'est à dire le premier parent de la fusion résultante est un commit sur leur histoire et sur le deuxième parent est le dernier mal un de votre histoire. Si vous vous retrouvez à l'aide de "checkout their-history && merge -s ours your-history" à
    garder le premier de la parentalité sensible.

    Et à ce moment, l'utilisation de "-s ours" n'est plus une solution de contournement pour le manque de "-s theirs".

    C'est une bonne partie, de la sémantique, c'est à dire du point de vue de la survie canoniques de l'histoire de la ligne, vous voulez conserver ce qu'il a fait, de détruire ce que l'autre de la ligne de l'histoire n'a.

    InformationsquelleAutor VonC
  12. 2

    Celui-ci utilise un git plomberie commande de lecture de l'arbre, mais fait pour une courte flux de travail global.

    git checkout <base-branch>

git merge --no-commit -s ours <their-branch>
git read-tree -u --reset <their-branch>
git commit

# Check your work!
git diff <their-branch>
    InformationsquelleAutor Michael R
  13. 0

    Cela va fusionner votre newBranch existants baseBranch

    git checkout <baseBranch> //this will checkout baseBranch
git merge -s ours <newBranch> //this will simple merge newBranch in baseBranch
git rm -rf . //this will remove all non references files from baseBranch (deleted in newBranch)
git checkout newBranch -- . //this will replace all conflicted files in baseBranch
    • Je suggère l'ajout de git commit --amend à la fin de votre exemple, ou les utilisateurs peuvent voir la fusion s'engager avec git log et supposons que l'opération est terminée.
    InformationsquelleAutor Pawan Maheshwari
  14. 0

    Je pense que ce que vous voulez vraiment est:

    git checkout -B mergeBranch branchB
git merge -s ours branchA
git checkout branchA
git merge mergeBranch
git branch -D mergeBranch

    Cela semble maladroit, mais il devrait fonctionner. La seule chose que je n'aime vraiment pas au sujet de cette solution est l'historique de git sera source de confusion... Mais au moins, l'histoire sera totalement préservée et vous n'aurez pas besoin de faire quelque chose de spécial pour les fichiers supprimés.

    InformationsquelleAutor briemers
  15. 0

    L'équivalent(qui garder les parents) afin de 'git merge -s leur branchB'

    Avant de fusion:Est-il “leur” version de “git merge -s nôtre”?

    !!! Assurez-vous que vous êtes en état de propreté !!!

    Faire de la fusion:

    git commit-tree -m "take theirs" -p HEAD -p branchB 'branchB^{tree}'
git reset --hard 36daf519952 # is the output of the prev command

    Ce que nous avons fait ?
    Nous avons créé un nouveau commit qui des deux parents de la nôtre et la leur et la contnet de la validation est branchB - leur

    Après fusion:Est-il “leur” version de “git merge -s nôtre”?

    Plus précisément:

    git commit-tree -m "take theirs" -p HEAD -p 'SOURCE^{commit}' 'SOURCE^{tree}'
    InformationsquelleAutor Boaz Nahum
  16. 0

    Cette réponse a été donnée par Paul Pladijs. J'ai juste pris ses commandements et fait un git alias pour des raisons de commodité.

    Modifier votre .gitconfig et ajoutez les éléments suivants:

    [alias]
    mergetheirs = "!git merge -s ours \"$1\" && git branch temp_THEIRS && git reset --hard \"$1\" && git reset --soft temp_THEIRS && git commit --amend && git branch -D temp_THEIRS"

    Ensuite, vous pouvez "git merge -s leur" en cours d'exécution:

    git checkout B (optional, just making sure we're on branch B)
git mergetheirs A
    InformationsquelleAutor Brain2000
  17. -1

    Récemment, j'ai besoin de faire cela pour deux référentiels qui partagent une histoire commune. J'ai commencé avec:

    • Org/repository1 master
    • Org/repository2 master

    Je voulais tous les changements de repository2 master être appliqué à repository1 master, d'accepter toutes les modifications que repository2 ferait. Dans git, l' devrait être une stratégie dite de -s theirs MAIS il n'existe pas. Être prudent, car -X theirs est nommé comme il le serait ce que vous voulez, mais il est PAS le même (il dit même si dans la page de man).

    La façon dont j'ai résolu ce problème a été d'aller à repository2 et de créer une nouvelle branche repo1-merge. Dans cette branche, j'ai couru git pull [email protected]:Org/repository1 -s ours et elle se confond bien avec pas de problèmes. J'ai ensuite pousser à la distance.

    Puis-je revenir à repository1 et de créer une nouvelle branche repo2-merge. Dans cette branche, je lance git pull [email protected]:Org/repository2 repo1-merge qui viendra compléter les questions.

    Enfin, il est nécessaire d'émettre une demande de fusion dans repository1 pour en faire le nouveau maître, ou simplement le garder comme une branche.

    InformationsquelleAutor Trann
  18. -1

    Une interface simple et intuitive (à mon avis) à deux étapes de la façon de le faire est

    git checkout branchB .
git commit -m "Picked up the content from branchB"

    suivie par

    git merge -s ours branchB

    (qui marque les deux directions fusionnées)

    Le seul inconvénient est qu'il ne supprime pas les fichiers qui ont été supprimés dans branchB à partir de votre branche. Un simple diff entre les deux branches par la suite montrera si il y a de tels fichiers.

    Cette approche permet également clair à partir du journal de révision après ce qui a été fait et ce qui a été prévu.

    • cela peut être correcte pour la question d'origine, cependant l'OP mise à jour de la question, en 2008, de telle manière que cette réponse est incorrecte.
    InformationsquelleAutor Ruben