Обновления были отклонены, потому что верхушка вашей текущей ветки отстает

Я новичок в Git, поэтому не стесняйтесь относиться ко мне как к новичку.

У нас такой рабочий процесс. У нас есть филиал, по devкоторому я могу связаться origin/dev. Когда мы вносим изменения, мы создаем ответвление от dev:

git checkout -b FixForBug origin / dev

Теперь у меня есть ветка, FixForBugкоторая отслеживает (думаю, это правильное слово) origin/dev. Таким образом, если я сделаю это, git pullэто внесет новые изменения, и origin/devэто здорово. Теперь, когда я закончил исправление, я нажимаю на удаленную ветку с тем же именем.

Сначала я извлекаю любые изменения из origin/devи делаю перебазирование:

git pull --rebase

Затем я отправляю изменения в удаленную ветку с тем же именем:

git push origin FixForBug

Теперь на удаленном сервере есть ветка, и я могу создать запрос на перенос, чтобы это изменение было одобрено и снова слито с веткой dev. Я никогда ничего origin/devсебе не навязываю . Я предполагаю, что это довольно распространенный рабочий процесс.

В первый раз, когда я делаю git push, он отлично работает и создает удаленную ветку. Однако, если я нажимаю второй раз (допустим, во время проверки кода кто-то указывает на проблему), я получаю следующую ошибку:

ошибка: не удалось отправить некоторые ссылки на ' https://github.limeade.info/Limeade/product.git '. Подсказка: обновления были отклонены, потому что вершина вашей текущей ветки находится за подсказкой: ее удаленный аналог. Интегрируйте удаленные изменения (например, подсказку: 'git pull ...') перед повторным нажатием. Подсказка: подробности см. в «Примечании о быстрой перемотке вперед» в «git push --help».

Однако, если я делаю это, git statusон говорит, что я опережаю origin/devна 1 фиксацию (что имеет смысл), и если я следую подсказке и бегу git pull, он говорит, что все обновлено. Я думаю, это потому, что я перехожу в другую ветку, чем моя восходящая ветка. Я могу исправить эту проблему, запустив:

git push -f origin FixForBug

В этом случае, он будет толкать изменения в удаленной ветви, говоря (принудительное обновление) и все , что появляется , чтобы быть хорошим на удаленном филиале.

Мои вопросы:

Почему -fтребуется в этом сценарии? Обычно, когда вы что- то принуждаете , это потому, что вы делаете что-то неправильно или, по крайней мере, против стандартной практики. Могу ли я сделать это, или это что-то испортит в удаленной ветке или создаст проблемы для тех, кому в конечном итоге придется объединить мои материалы с разработчиком?

-f Это на самом деле требуется из-за перебазирования. Всякий раз, когда вы выполняете перебазирование, вам нужно будет выполнить принудительное нажатие, потому что удаленная ветвь не может быть быстро перенаправлена ​​на вашу фиксацию. Вы всегда хотели бы убедиться, что вы выполняете вытягивание, прежде чем нажимать, но если вам не нравится принудительно нажимать на master или dev, вы можете создать новую ветку для отправки, а затем объединить или сделать PR ,

Чтобы убедиться, что ваша локальная ветка FixForBug не опережает удаленную ветку, FixForBug извлекает и объединяет изменения перед отправкой.

git pull origin FixForBug
git push origin FixForBug

the tip of your current branch is behind its remote counterpartозначает, что в удаленной ветке произошли изменения, которых у вас нет локально. и git сообщает, что вы импортируете новые изменения REMOTEи объединяете их с вашим кодом, а затем pushна удаленный компьютер.

Вы можете использовать эту команду для принудительного внесения изменений на сервер с помощью local repo ().

git push -f origin master

с -fтегом, который вы замените Remote Brach codeсвоим кодом.

Если вы хотите избежать использования -f, вы можете использовать только

git pull

вместо того

git pull --rebase

При отсутствии перебазирования изменения будут извлечены из вашей ветки origin/devи объединены с ними FixForBug. Тогда вы сможете запустить

git push origin FixForBug

без использования -f.

Команда, которую я использовал с Azure DevOps, когда я обнаружил сообщение «обновления были отклонены, потому что верхняя часть вашей текущей ветки отстает», была / является следующей командой:

git pull origin master

(или можно начать с новой папки и сделать клонирование) ..

Этот ответ не касается поставленного вопроса, в частности, Кейф ответил на него выше, но он отвечает на заголовок / текст заголовка вопроса, и это будет распространенный вопрос для пользователей Azure DevOps.

Я заметил комментарий: «Вы всегда должны быть уверены, что делаете тягу, прежде чем толкать» в ответе Кейфа выше!

Я также использовал инструмент Git Gui в дополнение к инструменту командной строки Git.

(Я не был уверен, как сделать эквивалент команды командной строки «git pull origin master» в Git Gui, поэтому я вернулся в командную строку, чтобы сделать это).

На диаграмме показаны различные команды git для различных действий, которые вы, возможно, захотите предпринять:

Это случилось со мной.

• Вчера я сделал запрос нашему мастеру.
• Мой коллега просматривал его сегодня и увидел, что он не синхронизирован с нашей основной веткой, поэтому, чтобы помочь мне, он слил мастер с моей веткой.
• Я не знал, что он это сделал.
• Затем я слил мастер локально, попытался протолкнуть его, но это не удалось. Зачем? Поскольку слияние моего коллеги с мастером создало дополнительную фиксацию, которой у меня не было локально !

Решение: Потяните вниз по моей собственной отрасли , так я понимаю , что дополнительное обязательство. Затем верните его в мою удаленную ветку.

буквально то, что я сделал в своей ветке, было:

git pull
git push

Вот как я решил свою проблему

Предположим, что восходящая ветвь - это та, из которой вы разветвились, а origin - ваше репо, и вы хотите отправить MR / PR в восходящую ветвь.

У вас уже есть, скажем, около 4 коммитов, и вы получаете Updates were rejected because the tip of your current branch is behind.

Вот что я сделал

Во-первых, раздавите все свои 4 коммита

git rebase -i HEAD~4

Вы получите список коммитов с pickнаписанным на них. (открыт в редакторе)

пример

pick fda59df commit 1
pick x536897 commit 2
pick c01a668 commit 3
pick c011a77 commit 4

в

pick fda59df commit 1
squash x536897 commit 2
squash c01a668 commit 3
squash c011a77 commit 4

После этого вы можете сохранить комбинированный коммит

следующий

Вам нужно будет спрятать свою фиксацию

Вот как

git reset --soft HEAD~1
git stash

теперь переустановите свою ветку вверх по течению

git fetch upstream beta && git rebase upstream/beta

Теперь вставьте свой спрятанный коммит

git stash pop

зафиксировать эти изменения и подтолкнуть их

git add -A
git commit -m "[foo] - foobar commit"
git push origin fix/#123 -f

Это должно быть потому, что фиксация опережает ваш текущий толчок.

1) git pull origin "имя ветки, которую вы хотите нажать"

2) git rebase

если git rebase прошла успешно, то хорошо. В противном случае вы разрешаете все конфликты слияния локально и продолжаете его до тех пор, пока перебазирование с удаленным не будет успешным.

3) git rebase --continue

У меня возникла эта проблема при попытке нажать после перезагрузки через Visual Studio Code, моя проблема была решена путем простого копирования команды из окна вывода git и выполнения ее из окна терминала в Visual Studio Code.

В моем случае команда была примерно такой:

git push origin NameOfMyBranch:NameOfMyBranch

Вы, должно быть, добавили новые файлы в свои коммиты, которые не были отправлены. Проверьте файл и снова нажмите этот файл, и попробуйте потянуть / нажать, он будет работать. Это сработало для меня ..