Vous pouvez utiliser la stratégie de fusion «Nos»:

 $ git checkout staging $ git merge -s ours email # Merge twigs, but use our branch head 

Si vous voulez simplement que les deux twigs «email» et «staging» soient identiques, vous pouvez marquer la twig «email», puis réinitialiser la twig «email» à celle «staging»:

 $ git checkout email $ git tag old-email-branch $ git reset --hard staging 

Vous pouvez également rebaser la twig “staging” de la twig “email”. Mais le résultat contiendra la modification des deux twigs.

Les autres réponses m’ont donné les bons indices, mais ils n’ont pas complètement aidé.

Voici ce qui a fonctionné pour moi:

 $ git checkout email $ git tag old-email-branch # This is optional $ git reset --hard staging $ $ # Using a custom commit message for the merge below $ git merge -m 'Merge -s our where _ours_ is the branch staging' -s ours origin/email $ git push origin email 

Sans la quasortingème étape de la fusion avec notre stratégie, le push est considéré comme une mise à jour non rapide et sera rejeté (par GitHub).

J’ai vu plusieurs réponses et c’est la seule procédure qui me permet de résoudre ce problème sans conflit.

Si vous voulez toutes les modifications de branch_new dans branch_old, alors:

 git checkout branch_new git merge -s ours branch_old git checkout branch_old git merge branch_new 

une fois ces quatre commandes appliquées, vous pouvez pousser le branch_old sans aucun problème

Si vous êtes comme moi et que vous ne voulez pas gérer la fusion, vous pouvez suivre les étapes ci-dessus, à l’exception de l’utilisation de la force au lieu de la fusion, car cela créera une trace de papier journal distrayante:

 git checkout email git reset --hard staging git push origin email --force 

Note: Ceci est seulement si vous ne voulez VRAIMENT jamais voir les choses dans le courrier électronique à nouveau.

Je voulais fusionner deux twigs pour que tout le contenu de old_branch soit mis à jour avec le contenu de new_branch

Pour moi, cela a fonctionné comme un charme:

 $ git checkout new_branch $ git merge -m 'merge message' -s ours origin/old_branch $ git checkout old_branch $ git merge new_branch $ git push origin old_branch 

Que diriez-vous:

 git branch -D email git checkout staging git checkout -b email git push origin email --force-with-lease 

Les autres réponses semblaient incomplètes.
J’ai essayé ci-dessous en entier, et cela a bien fonctionné.

REMARQUE:
1. Faites une copie de votre référentiel avant d’essayer ci-dessous, pour être sûr.

Détails:
1. Tout le développement se passe en dev
2. qa est juste la même copie de dev
3. De temps en temps, le code dev doit être déplacé / écrasé dans la twig qa

nous devons donc remplacer la twig qa, de la twig dev

Partie 1:
Avec les commandes ci-dessus, l’ancienne qa a été mise à jour avec dev:

 git checkout dev git merge -s ours qa git checkout qa git merge dev git push 

Le commentaire automatique pour la dernière poussée donne ci-dessous:

 // Output: // * Merge branch 'qa' into dev,* 

Ce commentaire semble inversé, car la séquence ci-dessus semble également inversée

Partie 2:

Ci-dessous sont inattendus, de nouveaux commits locaux en dev, les inutiles
donc, nous devons jeter et rendre le développement inchangé.

 git checkout dev // Output: // Switched to branch 'dev' // Your branch is ahead of 'origin/dev' by 15 commits. // (use "git push" to publish your local commits) git reset --hard origin/dev // Now we threw away the unexpected commits 

Partie 3:
Vérifiez que tout est comme prévu:

 git status // Output: // *On branch dev // Your branch is up-to-date with 'origin/dev'. // nothing to commit, working tree clean* 

C’est tout.
1. l’ancien qa est maintenant écrasé par le nouveau code de twig dev
2. local est propre (l’origine / dev distante est intacte)

 git checkout email git merge -m "Making email same as staging disregarding any conflicts from email in the process" -s recursive -X theirs staging