Я встановив віддалений не голий "основний" репо і клонував його до свого комп'ютера. Я вніс декілька локальних змін, оновив своє місцеве сховище та перемістив зміни назад до віддаленого репорту. До цього моменту все було добре.

Тепер мені довелося щось змінити у віддаленому репо. Потім я щось змінив у своєму місцевому репо. Я зрозумів, що зміни на віддалений репо не потрібні. Тож я спробував перейти git pushз місцевого репо до мого віддаленого репо, але у мене виникла помилка на зразок:

Щоб не втратити історію, відхилені нешвидкісні оновлення назад Об’єднайте віддалені зміни, перш ніж натиснути знову. git push --helpДеталі див. У розділі "Примітка про швидку перемотку" .

Я думав, що, ймовірно, a

git push --force

змусить мою локальну копію натиснути зміни на віддалений і зробити їх такими ж. Це примушує оновлення , але коли я повертаюся до віддаленого репо і приймаю зобов’язання, я помічаю, що файли містять застарілі зміни (ті, які раніше мали головне віддалене репо).

Як я вже згадував у коментарях до однієї з відповідей :

[Я] спробував примусити, але, повертаючись на головний сервер, щоб зберегти зміни, я отримую застарілі постановки. Таким чином, коли я здійснюю сховища, то схожі. І коли я знову намагаюся використовувати git push, я отримую ту ж помилку.

Як я можу виправити це питання?

Просто зробіть:

git push origin <your_branch_name> --force

або якщо у вас є конкретне репо:

git push https://git.... --force

Це видалить ваші попередні зобов'язання та підштовхне ваше поточне.

Це може бути не правильно, але якщо хтось натрапить на цю сторінку, подумав, що може захотіти простого рішення ...

Короткий прапор

Також зауважте, що -fце коротко --force, тому

git push origin <your_branch_name> -f

також буде працювати.

І якщо push --forceце не працює, ви можете зробити push --delete. Подивіться на 2 - ^й лінії на цьому прикладі:

git reset --hard HEAD~3  # reset current branch to 3 commits ago
git push origin master --delete  # do a very very bad bad thing
git push origin master  # regular push

Але будьте обережні ...

Ніколи не повертайтеся до публічної історії git!

Іншими словами:

• Ніколи не forceнатискайте на загальнодоступне сховище.
• Не робіть цього чи нічого, що може зламати когось pull.
• Ніколи reset або rewriteісторія в репо хто - то , можливо, вже тягнув.

Звичайно, є виключно рідкісні винятки навіть із цього правила, але в більшості випадків цього не потрібно, і це створюватиме проблеми всім іншим.

Зробіть замість цього відновлення.

І завжди будьте уважні до того, що ви підштовхуєте до публічного репо . Повернення:

git revert -n HEAD~3..HEAD  # prepare a new commit reverting last 3 commits
git commit -m "sorry - revert last 3 commits because I was not careful"
git push origin master  # regular push

По суті, обидва джерела головки (від повернення та злого скидання) ) будуть містити однакові файли.

редагуйте, щоб додати оновлену інформацію та більше аргументів push --force

Розгляньте силу натискання з орендою замість натискання, але все ж віддайте перевагу відновленню

Ще одна проблема push --forceможе виникнути, коли хтось щось штовхне, перш ніж ти зробиш, але після того, як ти вже зібрався. Якщо ви натиснете на свою базовану версію, ви заміните роботу іншим .

git push --force-with-leaseВведений в git 1.8.5 ( завдяки коментарю @VonC до цього питання) намагається вирішити цю конкретну проблему. В основному, це призведе до помилки, а не натисне, якщо пульт змінено з останнього завантаження.

Це добре, якщо ви справді впевнені push --force, що потрібне, але все ж хочете запобігти більшим проблемам. Я б сказав, що це має бути push --forceповедінка за замовчуванням . Але це ще далеко не привід змусити а push. Люди, які зібралися перед вашою базою даних , все ще матимуть багато проблем, яких можна легко уникнути, якщо ви замість цього повернули .

А оскільки ми говоримо про git --pushвипадки ...

Чому хтось хоче змусити натискати?

@linquize привів гарний приклад сили коментарів: конфіденційні дані . Ви неправильно просочилися дані, які не слід висувати. Якщо ви досить швидкі, ви можете "виправити"* це, натиснувши на поштовх.

*Дані будуть по- , як і раніше перебувати на пульті дистанційного управління , якщо ви не робите сміття збирати , або очистити його яким - то чином . Існує також очевидний потенціал для того, щоб його поширювали інші, хто вже отримав це, але ви отримуєте ідею.

Перш за все, я не вносив би жодних змін безпосередньо в "головне" репо. Якщо ви дійсно хочете мати "головне" репо, тоді вам слід лише натиснути на нього, ніколи не змінювати його безпосередньо.

Щодо помилки, яку ви отримуєте, ви спробували git pullвід місцевого репо, а потім git pushдо головного репо? Те, що ви зараз робите (якщо я це добре зрозумів) - змушує натиснути, а потім втратити свої зміни в "головному" репо. Спершу слід змінити місцеві зміни.

Якщо я перебуваю на своїй локальній гілці A і хочу примусити натиснути локальну гілку B на початкову гілку CI, можна використовувати такий синтаксис:

git push --force origin B:C

використовувати цю наступну команду:

git push -f origin master

Я б дуже рекомендував:

• натисніть лише на основний репо

• переконайтеся, що main repo - це голе репо , щоб ніколи не виникало проблем з тим, щоб основне дерево робочого репо не синхронізувалося з його .gitбазою. Див. " Як перенести локальний сховище git на інший комп'ютер? "

• Якщо вам доведеться вносити модифікації в основний (голий) репо, клонуйте його (на головному сервері), зробіть свою модифікацію та натисніть на неї

Іншими словами, тримайте голий репо доступний як з основного сервера, так і з локального комп'ютера, щоб мати єдине репо вгору за течією, з / до якого потрібно тягнути / тягнути.

Це було нашим рішенням щодо заміни майстра у корпоративному сховищі gitHub при збереженні історії.

push -fосвоєння корпоративних сховищ часто відключено для підтримки історії філій. Це рішення працювало на нас.

git fetch desiredOrigin
git checkout -b master desiredOrigin/master // get origin master

git checkout currentBranch  // move to target branch
git merge -s ours master  // merge using ours over master
// vim will open for the commit message
git checkout master  // move to master
git merge currentBranch  // merge resolved changes into master

підштовхніть свою філію до desiredOriginта створіть PR

У мене було те саме питання, але я вирішив його нарешті. Що, швидше за все, вам потрібно зробити, це виконати наступні дві команди git (замінити хеш на номер редакції git commit):

git checkout <hash>
git push -f HEAD:master