Git push отклонен после перебазировки ветки

Хорошо, я думал, что это был простой сценарий мерзавца, что я пропускаю?

У меня есть masterфилиал и featureфилиал. Я работаю над masterнекоторыми, над некоторыми feature, а потом еще над некоторыми master. Я получаю что-то вроде этого (лексикографический порядок подразумевает порядок коммитов):

A--B--C------F--G  (master)
       \    
        D--E  (feature)

У меня нет проблем с обновлением git push origin masterпульта master, а также с git push origin feature(когда он включен feature) для сохранения удаленной резервной копии моей featureработы. До сих пор у нас все хорошо.

Но теперь я хочу перебазировать featureповерх F--Gкоммитов на мастере, поэтому я git checkout featureи git rebase master. Все еще хорош. Теперь у нас есть:

A--B--C------F--G  (master)
                 \
                  D'--E'  (feature)

Проблема: в момент, когда я хочу сделать резервную копию новой перебазированной ветки featureсgit push origin feature , толчок отклоняется, поскольку дерево изменилось из-за перебазировки. Это можно решить только с помощью git push --force origin feature.

Я ненавижу использовать, --forceне будучи уверенным, что мне это нужно. Так мне это нужно? Есть ли перебазирования обязательно означает , что следующий pushдолжен быть --forceFUL?

Эта ветвь функций не используется другими разработчиками, поэтому де-факто у меня нет проблем с принудительным нажатием, я не собираюсь терять какие-либо данные, вопрос более концептуальный.

Проблема заключается в том, что git pushпредполагается, что удаленная ветвь может быть быстро перенаправлена ​​в вашу локальную ветвь, то есть все различия между локальной и удаленной ветвями заключаются в том, что в конце есть несколько новых коммитов:

Z--X--R         <- origin/some-branch (can be fast-forwarded to Y commit)
       \        
        T--Y    <- some-branch

При выполнении git rebaseкоммитов D и E применяются к новой базе, и создаются новые коммиты. Это означает, что после перебазирования у вас есть что-то вроде этого:

A--B--C------F--G--D'--E'   <- feature-branch
       \  
        D--E                <- origin/feature-branch

В этой ситуации удаленная ветвь не может быть быстро переадресована на локальную. Хотя теоретически локальная ветвь может быть объединена с удаленной (очевидно, в этом случае она вам не нужна), но, поскольку она git pushвыполняет только быстрое слияние, она выдает и выдает ошибку.

И то, что можно сделать --force, это просто игнорировать состояние удаленной ветви и установить его в коммит, который вы вводите в него. Так что git push --force origin feature-branchпросто переопределяет origin/feature-branchс местным feature-branch.

На мой взгляд, перебазирование ветвей функций masterи принудительное возвращение их в удаленный репозиторий - это нормально, если вы единственный, кто работает в этой ветке.

Вместо использования -f или --force разработчики должны использовать

--force-with-lease

Почему? Потому что он проверяет удаленную ветку на наличие изменений, что является хорошей идеей. Давайте представим, что Джеймс и Лиза работают над одной и той же веткой функций, а Лиза выдвинула коммит. Джеймс теперь перебазирует свою местную ветку и отклоняется при попытке подтолкнуть. Конечно, Джеймс думает, что это связано с перебазированием и использует --force, и переписал бы все изменения Лизы. Если бы Джеймс использовал --force-with-lease, он бы получил предупреждение о том, что кто-то другой совершил коммиты. Я не понимаю, почему кто-то будет использовать --force вместо --force-with-lease при нажатии после ребазинга.

Я бы использовал вместо "checkout -b", и это легче понять.

git checkout myFeature
git rebase master
git push origin --delete myFeature
git push origin myFeature

когда вы удаляете, вы не можете нажать на выходящую ветку с другим идентификатором SHA. Я удаляю только удаленную ветку в этом случае.

Одно из решений этой проблемы - сделать то, что делает сценарий слияния msysGit: после слияния слить в старый заголовокfeature с -s ours. В итоге вы получите граф фиксации:

A--B--C------F--G (master)
       \         \
        \         D'--E' (feature)
         \           /
          \       --
           \    /
            D--E (old-feature)

... и ваш толчок featureбудет ускоренной.

Другими словами, вы можете сделать:

git checkout feature
git branch old-feature
git rebase master
git merge -s ours old-feature
git push origin feature

(Не проверено, но я думаю, что это правильно ...)

Может быть, а может и нет, что в этой ветке есть только один разработчик, который сейчас (после ребазинга) не соответствует источнику / функции.

В качестве такового я бы предложил использовать следующую последовательность:

git rebase master
git checkout -b feature_branch_2
git push origin feature_branch_2

Да, новая ветка, это должно решить эту проблему без --force, что, на мой взгляд, является основным недостатком git.

Мой способ избежать принудительного нажатия - создать новую ветку и продолжить работу над этой новой веткой и после некоторой стабильности удалить старую ветку, которая была перебазирована:

• Перебазирование проверенной ветки локально
• Ветвление из перебазированной ветки в новую ветку
• Раздвигая эту ветку как новую ветку к удаленной. и удаление старой ветки на удаленной

Другие ответили на ваш вопрос. Если вы перебазируете ветку, вам нужно будет принудительно нажать на эту ветку.

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

В целом, rebase хорошо работает для местного филиала. Удаленное управление ветками лучше всего работает с явными слияниями (--no-ff).

Мы также избегаем слияния мастера в ветку функций. Вместо этого мы перебазируем на master, но с новым именем ветви (например, добавив суффикс версии). Это позволяет избежать проблемы перебазирования в общем хранилище.

Что не так с git merge masterна featureветке? Это сохранит работу, которую вы имели, сохранив ее отдельно от основной ветки.

A--B--C------F--G
       \         \
        D--E------H

Изменить: Ах, извините, не прочитал вашу проблему. Вам понадобится сила, поскольку вы выполнили rebase. Все команды, которые изменяют историю, будут нуждаться в --forceаргументе. Это отказоустойчивый, чтобы предотвратить потерю работы (старые Dи Eбудут потеряны).

Итак, вы выполнили операцию, git rebaseкоторая заставила дерево выглядеть (хотя частично скрыто Dи Eбольше не находится в именованной ветви):

A--B--C------F--G
       \         \
        D--E      D'--E'

Таким образом, при попытке протолкнуть новую featureветку (с D'и E'в ней), вы потеряете Dи E.

Для меня работает следующие простые шаги:

1. git checkout myFeature
2. git rebase master
3. git push --force-with-lease
4. git branch -f master HEAD
5. git checkout master
6. git pull

После всего вышеперечисленного, мы также можем удалить ветку myFeature, выполнив следующую команду:

git push origin --delete myFeature

Следующие работы для меня:

git push -f origin branch_name

и это не удаляет любой мой код.

Но, если вы хотите избежать этого, вы можете сделать следующее:

git checkout master
git pull --rebase
git checkout -b new_branch_name

тогда вы можете выбрать все свои коммиты в новую ветку. git cherry-pick COMMIT ID а затем нажмите вашу новую ветку.

Поскольку ОП понимает проблему, просто ищет более хорошее решение ...

Как насчет этого как практики?

• Имейте в реальной ветке разработки функций (где вы никогда не делаете ребаз и форс-пуш, чтобы ваши коллеги-разработчики не ненавидели вас). Здесь регулярно берут эти изменения с основного слияния. История МессьеДа, сложнее, но жизнь проста, и никто не вмешивается в его работу.

• Иметь вторую ветвь разработки функций, где один член команды функций регулярно выталкивает все функции, фактически перебазированные, действительно форсированные. Так что почти чисто на основе довольно недавнего мастер-коммита. По завершении функции нажмите эту ветку сверху мастера.

Для этого метода уже может быть имя шаблона.