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

Pushing to git@github.com:519ebayproject/519ebayproject.git
To git@github.com:519ebayproject/519ebayproject.git
 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 'git@github.com:519ebayproject/519ebayproject.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

У сховищі я ще нічого не штовхнув, тож навіщо мені щось тягнути?

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

Якщо ви не хочете об'єднати віддалену гілку у свою локальну гілку (див. Відмінності з git diff ), а ви хочете зробити натиск силою, скористайтесь командою push з -f

git push -f origin <branch>

де originназва вашого віддаленого репо.

Зазвичай команда відмовляється від оновлення віддаленого ref, який не є предком локального ref, який використовується для його перезапису. Цей прапор відключає чек. Це може призвести до втрати віддаленого сховища комісій; використовувати його обережно.

Як повідомляє повідомлення,

Об’єднайте віддалені зміни (наприклад, "git pull")

Використовуйте git pullдля перетягування останніх змін із віддаленого сховища до локального сховища. У цьому випадку для витягування змін потрібне об’єднання, оскільки ви внесли зміни до свого локального сховища.

Я надам приклад і малюнок для пояснення. Припустимо, ваш останній потяг з походження / відділення був у Комітеті B. Ви виконали та виконали певну роботу (Складіть С). У той же час хтось інший закінчив їх роботу і підштовхнув її до походження / відділення (Комітет D). Потрібно буде злиття цих двох гілок.

local branch:                         --- Commit C 
                                    /
                                   /
                                  /
origin/branch: Commit A ------ Commit B ---- Commit D

Оскільки ви є тим, хто хоче натиснути, Git змушує вас здійснити злиття. Для цього потрібно спочатку витягнути зміни з походження / гілки.

local branch:                         --- Commit C -- Commit E
                                    /               /           
                                   /               /             
                                  /               /               
origin/branch: Commit A ------ Commit B ---- Commit D 

Після завершення злиття вам тепер буде дозволено перемотати початкове походження / відділення до комісії Е, натиснувши ваші зміни.

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

Ви оновили код перед натисканням?

Використовуйте, git pull origin masterперш ніж щось натиснути.

Я припускаю, що ви використовуєте originяк ім'я для вашого дистанційного.

Вам потрібно потягнути перед натисканням, щоб оновити локальний сховище, перш ніж щось натиснути (на випадок, якщо хтось уже оновив код github.com). Це допомагає вирішувати конфлікти на місцях.

Зазвичай це відбувається, коли ви git commitнамагаєтесь git pushзмінитись раніше git pullingна тій гілці, xде хтось уже вніс зміни.

Нормальний потік буде таким, як нижче,

КРОК 1 : git stashваші місцеві незабезпечені зміни у цій гілці.

КРОК 2 : git pull origin branch_name -vдо pull and mergeлокально здійснених змін у цій гілці ( дайте цьому об'єднанню якесь повідомлення та виправте конфлікти, якщо такі є ).

КРОК 3 : зміни git stash popв stashредакторі ( тоді ви можете зробити фіксацію на спливаючих файлах, якщо ви хочете, або спочатку натисніть на вже здійснені зміни (STEP4) і пізніше зробіть нову фіксацію файлів. )

КРОК 4 : git push origin branch_name -vоб'єднані зміни.

Замініть branch_nameна master(для masterгілки).

Перше і просте рішення (не рекомендується)

• Спробуйте цю команду git push -f origin master.
• Ця команда примусово замінить віддалений сховище (GitHub)

Рекомендоване рішення

• Виконайте ці команди:

git pull --allow-unrelated-histories  //this might give you error but nothing to worry, next cmd will fix it
git add *
git commit -m "commit message"
git push

Якщо це не працює, виконайте наступні дії 🔰

• Видалити .gitкаталог з папки.

• Потім виконайте ці команди:

  git init
  git add .
  git commit -m "First Commit"
  git remote add origin [url]
  git push -u origin master
  

АБО

git push -f origin master 

Використовуйте лише, git push -f origin masterякщо ви -uне працюєте.

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

Іноді ми забували про потяг і робили багато робіт у місцевих умовах.

Якщо хтось хоче натиснути без тяги,

git push --force

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

Деякі з вас можуть отримати цю помилку, оскільки Git не знає, яку галузь ви намагаєтеся натиснути.

Якщо ваше повідомлення про помилку також включає

error: failed to push some refs to 'git@github.com:jkubicek/my_proj.git'
hint: Updates were rejected because a pushed branch tip is behind its remote
hint: counterpart. If you did not intend to push that branch, you may want to
hint: specify branches to push or set the 'push.default' configuration
hint: variable to 'current' or 'upstream' to push only the current branch.

то, можливо, ви захочете дотримуватися зручних порад від Джима Кубічека, Налаштувати Git на лише Push Current Branch , щоб встановити гілку за замовчуванням на поточну.

git config --global push.default current

git pull origin branch_name --rebase

Це працювало для мене - команда git pull origin branch_name --rebaseспочатку буде витягувати зміни з віддаленого імені гілки, а потім з rebaseпоточної гілки вгорі.

На додаток до вищезазначених відповідей для мене працювало:

Сценарій -

1. Я успішно підштовхнув my_branch до походження.
2. Я вніс ще кілька змін.
3. Коли я знову спробував натиснути, (зробивши додавання, виконувати звичайно), у мене з’явилася вищезгадана помилка.

Рішення -

 1. git checkout **my_branch**
 2. git add, commit your changes.
 3. git pull origin **my_branch** (not origin, master, or develop)
 4. git push origin **my_branch**

У мене була така ж проблема, що я робив, коли я спочатку її силою натиснув на це

git push --force

Я зробив це після того, як я зв'язав файли і отримав помилку, як ви отримали. Я зробив всі файли, і це їх натиснуло. Потім наступного разу я штовхнув до github. Я зробив те, про що мене просили, і тоді все було добре. Сподіваюся, це теж працює для вас :)

Про це я згадував у своєму підручнику « Як користуватися GitHub: Підручник для початківців» .

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

git pull https://github.com/thomas07vt/MyFirstRepo.git master

git push https://github.com/thomas07vt/MyFirstRepo.git master

Я отримував вищезгадане повідомлення про помилку, коли намагався натиснути на свою поточну гілку foobar:

git checkout foobar
git push origin foo

Виявляється, у мене були дві локальні гілки, які відстежували ту ж віддалену гілку:

foo -> origin/foo (some old branch)
foobar -> origin/foo (my current working branch)

Мені підштурхнуло мою поточну гілку, використовуючи:

git push origin foobar:foo

... і чистити с git branch -d

git push -f походження назви гілки

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

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

Рішення . Ви можете просто перетягнути вміст папки в іншу папку, перетягнути проект у свою тепер порожню папку, перетягнути витягнутий вміст у смітник, а потім перетягнути правильний проект назад у папку. Ви повинні вміти правильно натискати і отримувати бажані результати. Для цього буквально потрібно менше 10 секунд.

Людям, які сказали б мені, що це не правильно, не наводячи жодних наслідків, або людям, які говорять мені використовувати команду, яка викликає у мене майбутні роздратування, я кажу: "Цей метод буквально займає у мене менше 10 секунд". Якщо я зіткнуся з командою git, яка потребує менше 10 секунд для виконання та має такий же ефект, я прийму це. До цього часу я використовую цей метод.

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

У мене була та сама проблема, але в моєму випадку я набрав неправильну гілку на пульті. Отож, здається, це ще одне джерело цього питання ... перевірте, чи не натискаєте ви на правильну гілку.

Я відчув ту саму проблему, і виявилося, що я був на іншій (місцевій) гілці, ніж я думав, що я І правильна місцева гілка відстала в комітетах віддалено.

Моє рішення: перевірка правильної гілки, вишня вибору комітету з іншої місцевої гілки, git pull та git push

У мене було подібне питання, і виявилося, що мій робочий процес із забезпечення актуальності своєї філії був винним. Я робив наступне:

У мого місцевого "господаря"

git fetch upstream
git merge upstream/master --ff-only

потім назад у моєму місцевому відділенні

git rebase master

Це добре працювало для попереднього git потоку, але не з github. Тут git rebaseбула проблема, що спричиняла проблеми із синхронізацією (і я визнаю, це те, що мені довелося прийняти без повного розуміння) і, на жаль, поставило мене в становище, де git push -fстало, мабуть, найпростішим варіантом. Не добре.

Мій новий потік - оновити гілку безпосередньо, використовуючи git mergeнаступне:

У моєму місцевому відділенні

git fetch upstream
git merge upstream/master

Ніякого швидкого руху вперед, оскільки я вніс зміни в курсі місцевого відділення.

Як ви, напевно, можете сказати, я не фахівець з git, але я надійно поінформований, що цей робочий процес, ймовірно, уникне конкретних проблем, які у мене виникли.

У моєму випадку я перевірив "мою галузь" і зробив git pull, тому не міг зрозуміти, чому натискання не працює. Врешті-решт я зрозумів, що штовхаю неправильну гілку. Я набирав текст git push origin masterзамість git push origin mybranch.

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

Чи назва вашої філії збігається з назвою віддаленої гілки?

Якщо ні, то слід оформити нову гілку з такою ж назвою, що й віддалену гілку, та спробувати натиснути її ще раз.

Припустимо, що віддалена гілка, яку ви хочете натиснути, - це [ тестування ], а ваша локальна гілка названа як [ тест ].

Якщо ви не знаходитесь у тестовій гілці, спочатку перейдіть на неї.

git checkout test

Потім відкрийте нову гілку і назвіть її тестуванням .

git checkout -b testing

Тепер саме час натиснути:

git push [remote repo] testing

Я вирішив цю проблему в моєму сховищі GIT. У цьому випадку не потрібно rebaseі не forceвчиняється. Щоб вирішити це, виконайте наведені нижче дії -

local_barnch> git branch --set-upstream to=origin/<local_branch_name> 

local_barnch>git pull origin <local_branch_name>

local_barnch> git branch --set-upstream to=origin/master

local_barnch>git push origin <local_branch_name>

сподіваюся, що це допоможе.

Ще одне рішення - просунути головку дистанційного, зробивши ще одну фіксацію, якщо можете. Після того, як ви втягнете цю просунуту голову в місцеве піддерево, ви зможете знову відштовхнутися від неї.

Я отримував подібну помилку під час натискання останніх змін у голому сховищі Git, яке я використовую для gitweb . У моєму випадку я не вніс жодних змін у голое сховище, тому просто видалив оголене сховище та знову клонував:

git clone --bare <source repo path> <target bare repo path>

Якщо ви впевнені, що у вашому сховищі git ніхто не вносив змін і ви працюєте над останньою версією, git pullце не має сенсу як рішення у вашому серці ...

Тоді, мабуть, те, що трапилось, ви використовували git commit --amend

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

Навчальний посібник ATLASSIAN: переписування історії

Однак це не рекомендується виконувати, git commit --amend якщо ви вже натиснули зобов’язання на GitHub , це тому, що "внесення змін не просто змінює останню прихильність - вона повністю замінює її. Для Git це буде виглядати як абсолютно новий комітет". що означає для інших розробників вашого GitHub, історія виглядає як A-> B-> C, але для вас це схоже на A-> B-> D, якщо GitHub дозволить вам push, всім іншим доведеться вручну виправити свою історію

Це причина, чому ви отримуєте повідомлення про помилку ! [rejected] master -> master (non-fast-forward), якщо ви знаєте, що ніхто не стягнув вашу останню зміну, ви можете це зробити git push --force, це змінить історію git у вашому публічному репо . Інакше ... ти можеш виступати git pull, але я вважаю, що це матиме такий самий результат, як ти не пройшовgit commit --amend , це створить нову фіксацію (тобто: git history after git pull: A-> B-> C-> D )

для більш детальної інформації: Як змінити останню комісію

Ще один варіант: локально перейменуйте свою філію на щось нове.

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

Ви можете отримати віддалену гілку, щоб мати локальну копію та вивчити відмінності між (i) тим, що мав віддалений (зі старою назвою гілки) та (ii), що у вас є (з новою назвою гілки), і вирішити, що робити . Оскільки ви в першу чергу не знали про відмінності віддалених пристроїв (звідси проблема), просто об'єднати чи примусити зміни десь занадто жорстокі.

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

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

Проблема з push командою полягає в тому, що ваше місцеве та віддалене сховище не відповідають. Якщо ви ініціалізуєте readme за замовчуванням під час створення нового сховища з git hub, то головна гілка автоматично створюється. Однак, коли ви намагаєтесь натиснути, це не має жодної гілки. Ви не можете натиснути ... Отже, найкраща практика - створити репо без ініціалізації readme за замовчуванням.

Ця проблема зазвичай викликана створенням файла readme.md, який зараховується як фіксація, не синхронізується локально в системі і не вистачає за головою, отже, він відображає запит git pull. Ви можете спробувати уникнути файла readme, а потім спробувати здійснити. Це спрацювало в моєму випадку.

Ще одна причина цієї проблеми (мабуть, не така поширена) ...

Мій сервер був позаду 12 годин, коли я натиснув

Я налаштував NTP на сервері SYNC мій годинник.

Я виконав новий git push, який призвів до помилки, обговореної в цій публікації.

Якщо випадково git pullдрукується, Already up-to-dateтоді ви можете перевірити глобальний push.defaultпараметр git (In ~/.gitconfig). Встановіть його, simpleякщо він був у matching. Відповідь нижче пояснює, чому:

Git - чим відрізняється push.default "відповідність" від "simple"

Крім того, варто перевірити, чи ваша місцева філія застаріла, git remote show originі при необхідності здійснити витяг

використовувати git pull https://github.com/username/repository Це тому, що Github та віддалені сховища не синхронізуються. Якщо ви pullрепо і потім Pushвсе буде синхронізовано, помилка піде.

`

git pull друкує Вже up-to-date

рішення:

ви можете створити сховище / проект у віддаленому (сервері) і додавши туди якийсь файл. Потім знову створили папку у вашому локальному і ініціалізованому git git init- це помилка , ви не повинні створювати git initв локальному, а замість цього клонувати проект у свій локальний використовуючиgit clone

потім тягніть