git push говорить "все актуально", навіть якщо я маю місцеві зміни

У мене є віддалений сервер gitosis та локальне сховище git, і кожного разу, коли я вношу великі зміни в свій код, я також натискаю зміни на цьому сервері.

Але сьогодні я вважаю, що хоча я маю деякі локальні зміни та зобов’язані працювати з місцевим сховищем під час запуску git push origin master він говорить "Все актуально", але коли я використовую git cloneдля перевірки файлів на віддаленому сервері, він не містить останніх змін . І у мене є лише одна гілка з назвою "master" та один віддалений сервер під назвою "origin".

PS: Це те, що git відображається під час запуску ls-remote, я не впевнений, чи допомагає це

$ git ls-remote origin
df80d0c64b8e2c160d3d9b106b30aee9540b6ece        HEAD
df80d0c64b8e2c160d3d9b106b30aee9540b6ece        refs/heads/master
$ git ls-remote .
49c2cb46b9e798247898afdb079e76e40c9f77ea        HEAD
df80d0c64b8e2c160d3d9b106b30aee9540b6ece        refs/heads/master
df80d0c64b8e2c160d3d9b106b30aee9540b6ece        refs/remotes/origin/master
3a04c3ea9b81252b0626b760f0a7766b81652c0c        refs/tags/stage3

Ви працюєте з відстороненою головою випадково?

А саме:

що вказує на те, що останнє зобов’язання не є керівником відділення.

Попередження : робиться наступне git reset --hard: переконайтеся, що спочатку скористаєтесь, git stashякщо ви хочете зберегти свої змінені файли.

$ git log -1
# note the SHA-1 of latest commit
$ git checkout master
# reset your branch head to your previously detached commit
$ git reset --hard <commit-id>

Як згадується на git checkoutсторінці "man" (моє значення)

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

$ git checkout v2.6.18

Раніші версії git не дозволяли цього і попросили створити тимчасову гілку за допомогою -b опцію, але, починаючи з версії 1.5.0, вищевказана команда відлучає вас HEADвід поточної гілки та безпосередньо вказує на коміт, названий тегом ( v2.6.18у приклад вище).

Ви можете використовувати всі команди git, перебуваючи в цьому стані.
Ви можете використовувати git reset --hard $othercommitдля подальшого переміщення, наприклад.
Ви можете внести зміни та створити нову комісію на верхній частині відокремленої ГОЛА .
Ви навіть можете створити злиття, використовуючи git merge $othercommit.

Стан, у якому ви перебуваєте, поки ваша HEAD від'єднана, не фіксується жодною гілкою (що природно --- ви не маєте жодної гілки).
Це означає, що ви можете відмовитись від тимчасових зобов’язань і злиття, повернувшись до існуючої гілки (наприклад git checkout master), а пізніше git pruneабо git gcзібравши їх сміття.
Якщо ви зробили це помилково, ви можете запитати рефлог про HEAD, де ви були, наприклад

$ git log -g -2 HEAD

Помилка .. Якщо ви git noob, ви впевнені, що git commitраніше git push? Я помилився вперше!

Можливо, ви просуваєте нову місцеву гілку?

Нове місцеве відділення повинно бути висунуто явно:

git push origin your-new-branch-name

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

Проблема полягала в тому, що моя місцева філія мала іншу назву, ніж віддалена. Мені вдалося натиснути, зробивши наступне:

$ git push origin local-branch-name:remote-branch-name

(Заслуга https://penandpants.com/2013/02/07/git-pushing-to-a-remote-branch-with-a-different-name/ )

Ще одна ситуація, яку важливо пам’ятати: такий стан за замовчуванням для git полягає в тому, що ви працюєте у гілці «master». І для багатьох ситуацій ви просто будете тусуватися як ваша основна робоча галузь (хоча деякі люди захоплюються і займаються іншими справами).

У всякому разі, це лише одна галузь. Тож ситуація, в яку я можу потрапити:

Моя активна галузь насправді НЕ головна галузь. ... Але я звично виконую команду: git push(і я раніше це робивgit push origin master , тож це ярлик для ТОГО).

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

Але я забув, що зміни, над якими я працював, ще не в головній галузі !!!

Тож тому щоразу, коли я намагаюся git push, і бачу "Все актуальне", я хочу кричати, але, звичайно, це не винна гіт! Це моє.

Тому замість цього я зливаю свою гілку в майстра, а потім натискаю, і все знову щасливе.

$ git push origin local_branch:remote_branch

Пояснення

У мене була така ж помилка, і я витратив години, намагаючись зрозуміти це. Нарешті я його знайшов. Що я не знав, це те, що при такому натисканні git push origin branch-xнамагатиметься шукати гілку-x локально, а потім переходити до віддаленої гілки-х.

У моєму випадку у мене було два віддалені URL-адреси. Я зробив переказ з гілки-x на гілку-у, коли намагався просунути з локально до локального x, у мене було повідомлення, що все актуально, це нормально, тому що я натискав на x другого пульта.

Короткий короткий опис, щоб не потрапити в цю пастку, вам потрібно вказати вихідний номер та цільовий коефіцієнт:

$ git push origin local_branch:remote_branch

Оновлення:

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

$ git push --set-upstream origin local_branch:remote_branch

Або

$ git push -u origin local_branch:remote_branch

Дивіться відповідь VonC вище - мені потрібен був додатковий крок:

$ git log -1
- note the SHA-1 of latest commit
$ git checkout master
- reset your branch head to your previously detached commit
$ git reset --hard <commit-id>

Я це робив, але коли я потім намагався git push remoterepo master, це сказав "помилка: не вдалося натиснути кілька посилань. Щоб уникнути втрати історії, відхилені нешвидкі оновлення вперед, об'єднайте віддалені зміни (наприклад," git pull ") перед знову натискати ».

Тож я зробив "git pull Remoterepo master", і це виявило конфлікт. Я git reset --hard <commit-id>знову, скопіював конфліктні файли в папку резервного копіювання, зробив git pull remoterepo masterзнову, скопіював конфліктні файли назад у мій проект, зробив git commit, тоді git push remoterepo master, і цього разу це спрацювало.

Гіт перестав говорити "все актуально" - і перестав скаржитися на "швидкі вперед".

Я зіткнувся з подібною ситуацією; коли я вніс зміни та спробував git push origin master, він сказав, що все актуально.

Мені довелося git addзмінити файл і потім git push origin master. Він почав працювати з цього моменту.

З вашого статусу git у вас, мабуть, ситуація відрізняється від моєї.

Але все одно, ось що зі мною трапилось .. Я зіткнувся з такою помилкою:

fatal: The remote end hung up unexpectedly
Everything up-to-date

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

git config http.postBuffer 524288000

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

Нещодавно моє сховище переїхало, але у мене була місцева копія. Я відгалужувався від свого місцевого «головного» відділення і вніс деякі зміни - і тоді я згадав, що сховище перемістилося. Раніше я git remote set-url origin https://<my_new_repository_url>встановлював нову URL-адресу, але коли я натиснув, то просто сказав "Все актуально", а не підштовхувати свою нову гілку до майстра.

Я врешті-решт вирішив це, перезавантажившись, origin/masterа потім натиснувши на явні назви гілок, як це:

$ git rebase <my_branch> origin/master
$ git push origin <my_branch>

Я сподіваюся, що це допоможе кожному, у кого була моя однакова проблема!

Супер рідко - але все-таки: У Windows можливо, що в упакованих реф-кодах є відділення з однієї літери (наприклад, dev / mybranch), а refs папці є інший випадок (наприклад, Dev / mybranch), коли для core.ignorecase встановлено значення true .

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

Я сам наткнувся на це, коли з’єднав гілку на Github і продовжував розвиватися в ній на місцях. Моє виправлення було трохи іншим, ніж інші, які були запропоновані.

Спочатку я розгалужив нову локальну гілку зі своєї старої місцевої гілки (яку я не міг натиснути). Потім я натиснув нову локальну гілку на початковий сервер (Github). Тобто

$ git checkout -b newlocalbranch oldlocalbranch
$ git push origin newlocalbranch

Це призвело до появи змін на Github, хоча і в новій локальній галузі, а не на старій місцевій галузі.

У моєму випадку у мене було 2 віддалених репости.

git remote -v
originhttps https://asim_kt@...
originhttps https://asim_kt@...
origin  ssh:git@bitbucket.org:...
origin  ssh:git@bitbucket.org:...

Обидва репо були однакові. Просто один був httpsінший ssh. Тож видалення небажаного (У моєму випадку, sshоскільки я використовував, httpsбо sshне працював!) Вирішив проблему для мене.

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

[colin] ~/github/rentap.js [master] M % git commit 'figured out some more stuff with the forms in views and started figuring out row and mode in models so also made matching routes and controllers'
error: pathspec 'figured out some more stuff with the forms in views and started figuring out row and mode in models so also made matching routes and controllers' did not match any file(s) known to git.
[colin] ~/github/rentap.js [master] M % git push
Enter passphrase for key '/home/colin/.ssh/id_ecdsa': 
Everything up-to-date

Виправили це, поставивши -amтам, де зазвичай роблю:

[colin] ~/github/rentap.js [master] M % git commit -am 'figured out some more stuff with the forms in views and started figuring out row and mode in models so also made matching routes and controllers'

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

git push origin master

І це показує повідомлення Everything up-to-date .

щоб виправити цю проблему, спробуйте виконати ці кроки

1. git add .
2. git commit -m "Bug Fixed"
3. git push -u origin master

Переконайтеся, що ви не знайшли свою віддалену URL-адресу.

Я просто хотів також зазначити, що я зіткнувся з цим після ввімкнення Git як CVS в локальній конфігурації Jenkins. Здається, що Дженкінс перевірив останню версію філії, яку я дав їй, а також скинув пульт, щоб відповідати шляхам, які я дав до репо. Довелося ще раз перевірити мою гілку функцій та виправити мою початкову віддалену URL-адресу "git remote set-url". Не вказуйте інструмент збирання на робочий каталог, або у вас буде поганий час. У моєму пульті було встановлено шлях до файлу до мого робочого каталогу, тому він, природно, повідомляв про все сучасне, коли я намагався натиснути зміни з тим самим джерелом та пунктом призначення.

Інша можливість полягає в тому, що ви назвали каталог у вашому .gitignore файлі, який вилучили. Таким чином, нові комісії не будуть висунуті. Мені сталося, що я назвав каталог, щоб ігнорувати "пошук", але це був також каталог у моєму дереві-джерелі.

Я знайшов швидкий шлях. Перейдіть у свою папку .git, відкрийте HEADфайл і змініть будь-яку гілку, на якій ви знаходилися назад, на головну. Наприклад, посилання:refs/heads/master

У мене було те саме питання. У моєму випадку це було спричинено тим, що потрібно було називати той самий пульт. Це створило стандартне "походження", але я давно використовую "github" як свій пульт, і це теж було. Як тільки я видалив пульт 'origin', помилка усунулася.

У мене це сталося (коміти в моєму журналі git не були на GitHub, хоча git сказав, що все актуально), і я впевнений, що проблема була в Github. Я не отримував жодних повідомлень про помилки в git, але у GitHub були помилки у статусі, і мої комісії були там через кілька годин.

https://status.github.com/messages

Повідомлення про статус GitHub були:

• Ми розслідуємо повідомлення про недоступність послуги.
• Ми розслідуємо проблеми з доступом до GitHub.com.
• Ми не працюємо над системою зберігання даних, щоб відновити доступ до GitHub.com.

Ще одна дуже проста, але непомітна моя помилка: я просто забув додати -mмодифікатор повідомлень у своїх зобов'язаннях. Тому я написав:

git commit 'My message'

Замість правильного:

git commit -m 'My message'

ПРИМІТКА: НЕ кидає жодних помилок! Але ви не зможете підштовхнути свої зобов'язання і завжди отримаєте Everything up to dateнатомість

тут моє рішення відрізняється від наведеного. Я не зрозумів, як трапляється ця проблема, але я її вирішив. трохи несподівано

тепер виходить:

$ git push origin  use_local_cache_v1
Everything up-to-date
$ git status
On branch test
Your branch is ahead of 'origin/use_local_cache_v1' by 4 commits.
  (use "git push" to publish your local commits)
  ......
$ git push
fatal: The upstream branch of your current branch does not match
the name of your current branch.  To push to the upstream branch
on the remote, use

    git push origin HEAD:use_local_cache_v1

To push to the branch of the same name on the remote, use

    git push origin test
    
$ git push origin HEAD:use_local_cache_v1    
Total 0 (delta 0), reused 0 (delta 0)
remote:

команда, яка працює для мене, така

$git push origin HEAD:use_local_cache

Сподіваюся, ви, хлопці, якнайшвидше вийдете з цієї неприємності)

Я знаю, що це дуже старе, але в моєму випадку я це швидко виправив.

Я отримував цю саму помилку, будучи напередодні однієї фіксації master . Тоді я знайшов поточний пост переповнення стека. Однак перш ніж приступати до запропонованих ідей, я просто вирішив зробити нове зобов’язання і спробувати ще раз з поштовхом до походження, і це працювало безперебійно.

Не знаю чому, але, можливо, це корисно для когось іншого.

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

- .git
- README.md
- client/
 - package.json
 - example.js
- api/
 - requirements.txt
 - example.py

І я взяв на себе зобов’язання освоїти модифікацію README.md, потім побіг git subtree push --prefix client heroku-client masterі отримав повідомленняEverything up-to-date

Я працював з Jupyter-Notebook, коли зіткнувся з цією оманливою помилкою.

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

Але те, що я зробив, - це розміри моїх файлів трохи більше 1 МБ, а найбільший - майже 2 Мб . Я зменшив розмір файлу за допомогою Як я можу зменшити розмір файлу мого ноутбука iPython?техніка. Це допомогло зменшити розмір мого файлу, очистивши виходи. Я зміг підштовхнути код, відтепер він приніс розмір мого файлу в КБ.