мастер git rebase, а затем отправка исходной ветви приводит к ошибке без ускоренной перемотки вперед - PullRequest
7 голосов
/ 21 января 2012

Я пытаюсь работать над своей веткой featureA, обновляя ее по отношению к главной ветке.

Вот сценарий

git clone ssh://xxx/repo

git checkout -b featureA

$ git add file.txt

$ git commit -m 'adding file' 

$ git push origin featureA

, в то время как пара новых коммитов гденажата на источник master

git checkout master

git pull origin master

git checkout featureA

git rebase master

git push origin feature A
To ssh://xxx/repo
 ! [rejected]        featureA -> featureA (non-fast-forward)
error: failed to push some refs to 'ssh://xxx/repo'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again.  See the
'Note about fast-forwards' section of 'git push --help' for details.

Как я могу выполнить ребазинг, не заставляя сервер принять его?

Ответы [ 2 ]

9 голосов
/ 21 января 2012

Вы не можете нажать после перебазирования. Коммиты теперь имеют разные SHA1, поскольку их история отличается. Если обновленный ref не содержит старого ref в своем происхождении, это потенциально опасная операция, и git не допустит этого.

Ваша единственная альтернатива - слияние, если вы не хотите форсировать.

Форсирование не так уж и плохо, если вы работаете в одиночку, и вам не нужно, чтобы другие присоединялись к этой ветке.

5 голосов
/ 21 января 2012

Короткий ответ на ваш вопрос: вы можете сделать обратное, переместив мастер на функцию A (но пока не нажимайте), и сбросив функцию A до этой точки.

Это на самом деле вишня, выбирающая коммиты от мастера на featureA, недостатком является то, что вы получите дублирующие коммиты на двух ветвях. Это решит вашу непосредственную проблему (если это ваше намерение), но в долгосрочной перспективе вы не должны перебазировать коммиты, которые уже были перенесены в удаленную ветку. Лучшее решение в вашем сценарии - это слияние.

...