Ответ 1

Вы можете использовать стратегию слияния 'ours':

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

Ответ 2

Если вы хотите, чтобы две ветки "электронная почта" и "стадия" были одинаковыми, вы можете пометить ветку "email" , а затем reset ветку "email" на "промежуточную":

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

Вы также можете переустановить ветвь "постановки" в ветке "email" . Но результат будет содержать модификацию двух ветвей.

Ответ 3

Другие ответы дали мне правильные подсказки, но они не полностью помогли.

Вот что сработало для меня:

$ 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

Без четвертого шага слияния с нашей стратегией push считается обновлением без быстрой пересылки и будет отклонен (GitHub).

Ответ 4

Я видел несколько ответов и единственную процедуру, которая позволила мне исправить это без каких-либо конфликтов.

Если вы хотите, чтобы все изменения из branch_new в branch_old, а затем:

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

после применения этих четырех команд вы можете без проблем нажать push_old

Ответ 5

Если вы похожи на меня, и вы не хотите заниматься слиянием, вы можете выполнить описанные выше шаги, за исключением использования силы вместо слияния, потому что это создаст отвлекающий след журнальной бумаги:

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

Примечание. Это только в том случае, если вы ДЕЙСТВИТЕЛЬНО никогда не хотите снова видеть материал в электронной почте.

Ответ 6

Я хотел объединить две ветки, чтобы все содержимое в old_branch обновлялось с содержимым из new_branch

ДЛЯ МЕНЯ ЭТО РАБОТАЕТ КАК ОЧАРОВАТЬ!!!!

$ 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

Ответ 7

Как насчет:

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

Ответ 8

Другие ответы выглядели неполными.
С небольшим натяжением, я пробовал ниже в полном объеме, и он работал нормально.

Детали:
1. QAbranch - это та же самая копия dev
2. Все развитие происходит в dev
3. время от времени код dev должен быть перемещен/перезаписан на qa-ветку

поэтому нам нужно перезаписать qa-ветку, из ветки dev

Последовательность 1:

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

ПРИМЕЧАНИЯ:

• С помощью вышеприведенных команд старый QAbranch был обновлен до более нового dev

• Автоматический комментарий для последнего нажатия:

Объединить ветку "QAbranch" в dev,
 Этот комментарий выглядит обратным, потому что выше последовательность также выглядит обратным

Последовательность 2:

git checkout dev

теперь дает

Переключено на ветку 'dev'
Ваш филиал опережает "origin/dev" на 15 коммитов.
(используйте "git push", чтобы публиковать локальные коммиты)

Выше неожиданно (новые локальные коммиты в dev не нужны)
 поэтому нам нужно выбросить и сделать нетронутым.

Последовательность 3:

git reset --hard origin/dev

5. Теперь проверьте:

Последовательность 4:

git status

В ветке dev
Ваш филиал обновлен с помощью "origin/dev".
ничего не делать, работающее дерево чистое

Теперь все хорошо:
1. Старый QAbranch теперь перезаписывается новым кодом ветки dev
2. локальный чистый (удаленный источник /dev нетронутый)

Ответ 9

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