Оновлення було відхилено, оскільки кінчик поточної гілки позаду

Я новачок у Git, тому не соромтеся ставитися до мене як до новачка.

Наш робочий процес такий. У нас є відділення, до devякого я можу звернутися origin/dev. Коли ми робимо зміни, ми створюємо відгалуження dev:

git checkout -b походження FixForBug / dev

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

Спочатку я знімаю будь-які зміни origin/devі роблю перезавантаження:

git pull --база

Потім я натискаю зміни на віддалену гілку з однойменною назвою:

git push origin FixForBug

Тепер на віддаленому сервері є гілка, і я можу створити запит на потяг, щоб цю зміну було затверджено та об'єднано назад у гілку розробників. Я ніколи нічого не підштовхую до 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 Це на самому ділі потрібно через перебазування. Щоразу, коли ви робите ребайн, вам потрібно буде робити силовий натиск, оскільки віддалену гілку неможливо переадресувати до вашого виконання. Ви завжди хочете переконатися, що робите тягнення, перш ніж натискати, але якщо вам не подобається змушувати натискати на майстер або розробник з цього питання, ви можете створити нову гілку, щоб натиснути, а потім злитися або зробити PR .

Щоб переконатися, що ваша локальна філія FixForBug не випереджає віддалену гілку FixForBug, потягніть та з’єднайте зміни перед натисканням.

git pull origin FixForBug
git push origin FixForBug

Якщо ви хочете уникнути необхідності користуватися -f, то можете використовувати просто

git pull

замість

git pull --rebase

Нереалізація отримає зміни origin/devта об'єднає їх у вашу FixForBugгілку. Тоді ви зможете бігти

git push origin FixForBug

без використання -f.

the tip of your current branch is behind its remote counterpartозначає, що на віддаленій гілці відбулися зміни, яких ви не маєте локально. і git повідомляє, що ви імпортуєте нові зміни з них REMOTEі об'єднуєте їх зі своїм кодом, а потім pushвіддалено.

Ви можете використовувати цю команду для примусових змін до сервера з локальним репо ().

git push -f origin master

з -fтегом ви перекриєте Remote Brach codeваш код.

Команда, яку я використовував із Azure DevOps, коли я стикався з повідомленням "оновлення було відхилено, оскільки підказка вашої поточної гілки позаду" була / є цією командою:

git pull master master

(або можна почати з нової папки і зробити Клон) ..

Ця відповідь не стосується поставленого питання, зокрема, Кейф відповів на це вище, але він відповідає назви / тексту заголовка питання, і це буде загальним питанням для користувачів Azure DevOps.

Я зауважив коментар: "Ви завжди хочете переконатися, що робите тягнення, перш ніж натискати" у відповідь від Кейфа вище!

Я також використовував інструмент Git Gui на додаток до інструменту командного рядка Git.

(Я не знав, як зробити еквівалент команди командного рядка "git pull origin master" в Git Gui, тому я повернувся до командного рядка, щоб це зробити).

Діаграма, яка показує різні команди git для різних дій, які ви могли б зробити, - це ця:

Це зі мною щойно трапилось.

• Я вчора зробив клопотання про наш господар.
• Моя колега переглядала це сьогодні і побачила, що він не синхронізований з нашою головною галуззю, тому, маючи намір допомогти мені, він з’єднав майстра з моєю галуззю.
• Я не знав, що він це зробив.
• Тоді я об'єднав місцевого майстра, спробував його підштовхнути, але це не вдалося. Чому? Оскільки злиття мого колеги з майстром створило додатковий комітет у мене не було на місцях !

Рішення: Потягніть вниз свою власну гілку, щоб я отримав додаткові зобов'язання. Потім відсуньте її назад до моєї віддаленої гілки.

буквально те, що я робив на своїй гілці :

git pull
git push

Ось як я вирішив свою проблему

Припустимо, гілка вище за течією є тією, з якої ви роздвоєні, і походження є вашим репо, і ви хочете відправити 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 "назва гілки, яку ви хочете натиснути"

2) git rebase

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

3) git rebase - продовжувати

У мене виникла ця проблема при спробі натиснути на ребайн через Visual Studio Code, мою проблему вирішили, просто скопіювавши команду з вікна виведення git та виконавши її з вікна терміналу в Visual Studio Code.

У моєму випадку команда була чимось на кшталт:

git push origin NameOfMyBranch:NameOfMyBranch