please commit your changes or stash them before you merge что делать

Ошибки git «Your local changes to the following files would be overwritten by merge» и «Please commit your changes or stash them before you merge» (РЕШЕНО)

Чтобы синхронизировать (обновить) свой локальный репозиторий с удалённым, используется команда:

Но она может закончиться неудачей и вызвать следующую ошибку:

Суть ошибки в том, что на удалённом репозитории сделаны изменения, но они не могут быть приняты, поскольку в вашем локальном репозитории тоже сделаны изменения и в результате если будут приняты обновления, то ваши локальные данные потеряются.

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

В ошибке показан проблемный файл (в данном случае это data/cf-subnet.txt), для проверки, были изменения на удалённом репозитории или в вашем локальном репозитории, вы также можете использовать команду:

Она также покажет список не синхронизированных файлов.

Подсказка в ошибке предлагает сделать commit или stash.

Но вариантов исправить эту ошибку четыре.

1. Отправить изменения (сделать commit)

2. Сделать stash

Если вы не знаете, что такое stash, то stash это как стек, временное хранилище, куда вы можете отправить сделанные изменения, а затем вернуть их обратно.

Чтобы спрятать изменения, то есть сделать stash выполните:

Затем примите изменения из удалённого репозитория (git pull).

А затем верните свои изменения из stash:

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

3. Отменить локальные изменения

Чтобы сбросить изменения в локальном репозитории выполните команду:

4. Сбросить локальные изменения для определённого файла

Чтобы сделать это, используйте команду вида:

Заключение

Какой бы способ вы не выбрали, после любого из этих вариантов вы можете обновить свой локальный репозиторий до последней версии с помощью:

Источник

How do I resolve git saying «Commit your changes or stash them before you can merge»?

I made some updates on my local machine, pushed them to a remote repository, and now I’m trying to pull the changes to the server and I get the message;

and tried again and I get the same message. I’m assuming that w3tc changed something in the config file on the server. I don’t care whether the local copy or remote copy goes on the server (I suppose the remote one is best), I just want to be able to merge the rest of my changes (plugin updates).

19 Answers 19

You can’t merge with local modifications. Git protects you from losing potentially important changes.

You have three options:

Commit the change using

Stash it.

Stashing acts as a stack, where you can push changes, and you pop them in reverse order.

Do the merge, and then pull the stash:

Discard the local changes

Or: Discard local changes for a specific file

using git checkout filename

The first command stores your changes temporarily in the stash and removes them from the working directory.

The second command switches branches.

You can try one of the following methods:

rebase

For simple changes try rebasing on top of it while pulling the changes, e.g.

So it’ll apply your current branch on top of the upstream branch after fetching.

This is a potentially dangerous mode of operation. It rewrites history, which does not bode well when you published that history already. Do not use this option unless you have read git-rebase(1) carefully.

checkout

If you don’t care about your local changes, you can switch to other branch temporary (with force), and switch it back, e.g.

reset

If you don’t care about your local changes, try to reset it to HEAD (original state), e.g.

and try pull again

So the situation that I ran into was the following:

error: Your local changes to the following files would be overwritten by merge: wp-content/w3tc-config/master.php Please, commit your changes or stash them before you can merge.

except, right before that, was remote: so actually this:

remote: error: Your local changes to the following files would be overwritten by merge: some/file.ext Please, commit your changes or stash them before you can merge.

What was happening was (I think, not 100% positive) the git post receive hook was starting to run and screwing up due to movement changes in the remote server repository, which in theory, shouldn’t have been touched.

WARNING: This will delete untracked files, so it’s not a great answer to this question.

In my case, I didn’t want to keep the files, so this worked for me:

Git 2.11 and newer:

Older Git:

-x means ignored files are also removed as well as files unknown to git.

-d means remove untracked directories in addition to untracked files.

-f is required to force it to run.

For me this worked:

To keep record of your newly created files while resolving this issue:

If you have newly created files, you can create a patch of local changes, pull in remote merges and apply your local patch after the remote merge is complete as defined step by step below:

git apply mypatch.patch

As suggested by Anu, if you have issues applying patch, try:

Enjoy your continued work on your feature, and commit your local changes when done.

Asking for commit before pull

If needed :

This solved my error:

Move to master branch:

Move back to my branch: «A»

Commiting was not an option, as there was nothing to commit.

Stashing wasn’t an option because there was nothing to stash.

In my case, I backed up and then deleted the file that Git was complaining about, committed, then I was able to finally check out another branch.

I then replaced the file, copied back in the contents and continued as though nothing happened.

This is probably being caused by CRLF issues.

Use this to pull and force update:

I tried the first answer: git stash with the highest score but the error message still popped up, and then I found this article to commit the changes instead of stash ‘Reluctant Commit’

and the error message disappeared finally:

3: git checkout the-other-file-name

then it worked. hope this answer helps.:)

If you are using Git Extensions you should be able to find your local changes in the Working directory as shown below:

If you don’t see any changes, it’s probably because you are on a wrong sub-module. So check all the items with a submarine icon as shown below:

When you found some uncommitted change:

Before using reset think about using revert so you can always go back.

git reset vs git revert sonic0002 2019-02-02 08:26:39

When maintaining code using version control systems such as git, it is unavoidable that we need to rollback some wrong commits either due to bugs or temp code revert. In this case, rookie developers would be very nervous because they may get lost on what they should do to rollback their changes without affecting others, but to veteran developers, this is their routine work and they can show you different ways of doing that. In this post, we will introduce two major ones used frequently by developers.

What are their differences and corresponding use cases? We will discuss them in detail below. git reset Assuming we have below few commits.

Commit A and B are working commits, but commit C and D are bad commits. Now we want to rollback to commit B and drop commit C and D. Currently HEAD is pointing to commit D 5lk4er, we just need to point HEAD to commit B a0fvf8 to achieve what we want. It’s easy to use git reset command.

After executing above command, the HEAD will point to commit B.

But now the remote origin still has HEAD point to commit D, if we directly use git push to push the changes, it will not update the remote repo, we need to add a -f option to force pushing the changes.

The drawback of this method is that all the commits after HEAD will be gone once the reset is done. In case one day we found that some of the commits ate good ones and want to keep them, it is too late. Because of this, many companies forbid to use this method to rollback changes.

git revert The use of git revert is to create a new commit which reverts a previous commit. The HEAD will point to the new reverting commit. For the example of git reset above, what we need to do is just reverting commit D and then reverting commit C.

Now it creates two new commit D’ and C’,

In above example, we have only two commits to revert, so we can revert one by one. But what if there are lots of commits to revert? We can revert a range indeed.

This method would not have the disadvantage of git reset, it would point HEAD to newly created reverting commit and it is ok to directly push the changes to remote without using the -f option. Now let’s take a look at a more difficult example. Assuming we have three commits but the bad commit is the second commit.

It’s not a good idea to use git reset to rollback the commit B since we need to keep commit C as it is a good commit. Now we can revert commit C and B and then use cherry-pick to commit C again.

Источник

Как мне разрешить git сказать «Зафиксируйте свои изменения или спрячьте их до того, как вы сможете объединиться»?

Я сделал некоторые обновления на своем локальном компьютере, перенес их в удаленный репозиторий, и теперь я пытаюсь вытащить изменения на сервер, и я получаю сообщение;

ошибка: ваши локальные изменения в следующих файлах будут перезаписаны слиянием:

WP-содержание / W3TC-конфигурации / master.php

Пожалуйста, передайте свои изменения или спрячьте их, прежде чем сможете объединить.

и попробовал еще раз, и я получил то же сообщение. Я предполагаю, что что-то w3tc изменилось в файле конфигурации на сервере. Мне все равно, идет ли локальная копия или удаленная копия на сервер (я думаю, что удаленная копия лучше всего), я просто хочу иметь возможность объединить остальные мои изменения (обновления плагинов).

Вы не можете объединиться с локальными изменениями. Git защищает вас от потери потенциально важных изменений.

У вас есть три варианта:

Зафиксируйте изменения, используя

Спрятать это.

Шкатулка действует как стек, где вы можете помещать изменения и извлекать их в обратном порядке.

Чтобы спрятать, введите

Сделайте слияние, а затем вытяните тайник:

Откажитесь от локальных изменений

Или: отменить локальные изменения для определенного файла

с помощью git checkout filename

Первая команда временно сохраняет ваши изменения в тайнике и удаляет их из рабочего каталога.

Вторая команда переключает ветви.

Вы можете попробовать один из следующих методов:

перебазироваться

Для простых изменений попробуйте перебазировать поверх него, потянув за изменения, например:

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

Это потенциально опасный режим работы. Он переписывает историю, которая не сулит ничего хорошего, когда вы уже опубликовали эту историю. Не используйте эту опцию, если вы не прочитали git-rebase(1) внимательно.

проверять, выписываться

Если вас не волнуют ваши локальные изменения, вы можете переключиться на другую ветку временно (с применением силы) и переключить ее обратно, например,

сброс

Если вас не волнуют ваши локальные изменения, попробуйте сбросить его в HEAD (исходное состояние), например

и попробуйте снова потянуть

Итак, ситуация, с которой я столкнулся, была следующей:

ошибка: Ваши локальные изменения в следующих файлах будут перезаписаны слиянием: wp-content / w3tc-config / master.php Пожалуйста, передайте свои изменения или сохраните их перед тем, как объединить.

кроме, прямо перед этим, был удаленным: так на самом деле это:

remote: error: Ваши локальные изменения в следующих файлах будут перезаписаны слиянием: some / file.ext Пожалуйста, передайте свои изменения или сохраните их перед тем, как объединить.

То, что происходило, было (я думаю, не на 100% положительным), крюк получения git post начал работать и облажаться из-за изменений движения в репозитории удаленного сервера, которые теоретически не должны были быть затронуты.

Источник

Как игнорировать ошибку в «git pull» о моих локальных изменениях, которые будут перезаписаны слиянием?

Как игнорировать следующее сообщение об ошибке на git pull?

ваши локальные изменения в следующих файлах будут перезаписаны merge

что если я хочу перезаписать их?

чтобы быть ясным, я хочу только перезаписать определенные изменения, а не все.

25 ответов

если вы хотите удалить все локальные изменения из рабочей копии, просто спрячьте их:

если они вам больше не нужны, теперь вы можете бросить эту заначку:

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

хорошо с помощью двух других ответов я придумал прямое решение:

это работает для меня, чтобы переопределить все локальные изменения и не требует идентификации:

вот решение, которое отбрасывает поэтапные изменения:

вы можете либо зафиксировать изменения перед слиянием, либо сохранить их:

мое решение для решения этой проблемы было:

тогда я мог бы перезаписать файл через:

если ваш репозиторий содержит несколько файлов, которые удаляются из master :

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

затем потяните его снова, как обычно:

эта проблема заключается в том, что вы внесли изменения локально в файл / s и тот же файл/S существует с изменениями в репозитории Git, поэтому перед pull / push вам понадобятся локальные изменения stash:

для перезаписи локальных изменений одного файла:

заменить все локальные изменения (изменения во всех файлах):

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

иногда ничего из этого не работает. Досадно, из-за вещи LF я думаю, что будет работать удаление файлы затем потянуть. Не то чтобы я рекомендовал это решение, но если файл не существует, git не будет бесполезно сообщать вам, что ваши изменения (которые могут даже не быть изменениями) будут переопределены и позволят вам продолжить.

используйте на свой страх и риск.

вы можете использовать это для перезаписи файла

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

лучший способ решить эту проблему:

после этого вы можете перезаписать файл с:

это сработало для меня, чтобы отбросить изменения на живом удаленном сервере и вытащить из системы управления версиями GitHub:

Если вы хотите сохранить изменения на сервере, просто сливаются в новый элемент конфигурации. Метод обработки выглядит следующим образом:

возможно, вы не выполняете все операции. Ты знаешь, что делать дальше.

ниже команда работает, как ожидалось.

он переопределяет все локальные изменения, если они вам не нужны.

я игнорировал файл в моем РЕПО, и когда я это сделал git pull upstream master Я получил следующую ошибку:

ошибка: локальные изменения в следующие файлы будут переписаны слияния: myfile.Яш Пожалуйста, зафиксируйте свои изменения или спрячьте их, прежде чем вы сможете объединить. Аборт

чтобы решить это, я сделал следующее

на ветке master ваша ветка позади «origin / master» на 4 коммита, и можно быстро перемотать. (используйте «git pull» для обновления локального бранч)

никаких изменений для фиксации (используйте» git add «и/или»git commit-a»)

вот моя стратегия решения проблемы.

Постановка Задачи

нужно внести изменения в более чем 10 файлов. Мы пытались!—0—>, но мерзавец крикнул:

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

решение

мы были в грязный этап на самом деле, потому что файлы были в «промежуточной области» a.к.»индексная область» и некоторые из них находились в «головной области» a.к.»локальный каталог Git». И мы хотели забрать изменения с сервера.

проверьте эту ссылку для получения информации о различных этапах Git в ясной форме: этапы GIT

мы следовали следующему шаги

давайте поймем, когда и почему вам нужно тайник

если вы находитесь в грязный состояние, означает, что вы вносите изменения в свои файлы, а затем вы вынуждены, по любой причине,тянуть или переключатель в другой филиал для очень срочной работы, поэтому в этот момент Вы не можете тянуть или переключаться, пока не совершите изменение. The stash команда здесь как Рука помощи.

из книги ProGIT, 2-е издание:

часто, когда вы работаете над частью своего проекта, все в грязное состояние, и вы хотите немного переключить ветви, чтобы работать что-то еще. Проблема в том, что вы не хотите делать фиксацию наполовину законченная работа, чтобы вы могли вернуться к этому позже. Этот ответом на эту проблему является команда git stash. Припрятать берет грязное состояние вашего рабочего каталога, то есть измененные отслеживаемые файлы и поэтапные изменения-и сохраняет его в стопке незавершенных изменения, которые можно применить в любое время.

Я столкнулся с этим при вытягивании из Мастера.

Как я справился с этим, используя Visual Studio;

надеюсь, что это помогает!

Если эта ошибка из-за окончания строк,

будет работать. Я не совсем понимаю, почему это работает.

для Pycharm вы можете сделать Git— > Revert, а затем потянуть.

это сообщение также может произойти, если git-lfs используется, и указатель файла был перезаписан реальным файлом.

затем вы можете использовать:

полный выход из моего дела

Я пробовал, и это успешно, прежде чем тянуть, пусть зафиксировать все файлы, которые вы не зафиксировали, тогда вы не получите эти сообщения от AS.

это сбросит и удалит все неотслеженные файлы.

Источник

В одной лодке с «ублюдком»: 11 продвинутых советов по использованию Git

*»ублюдок» — вольный перевод слова «git» — «an unpleasant or contemptible person», «неприятный или презренный человек».

В комментариях к статье 15 базовых советов по Git для эффективной работы каждый день развернулась дискуссия на тему эффективности использования тех или иных команд и опций. Надо признать, что git предоставляет столько различного функционала, что во-первых, за всем становится невозможно уследить, а во-вторых, его можно совершенно по-разному вписывать в рабочий процесс.

1. Используйте консольный и графический интерфейсы git одновременно

Начнём с того, как именно Вы пользуетесь возможностями git? Многие работают строго из консоли или из приложения вроде SourceTree, и с первого взгляда может показаться, что эти варианты взаимоисключают друг друга.

Многие продвинутые редакторы, в частности, Ваш любимый vim мой любимый VS Code, предоставляют как удобный доступ к консоли, так и приятный графический интерфейс для систем контроля версий, что позволяет в равной мере использовать плюсы обоих вариантов.

Удобства графического интерфейса очевидны невооружённым взглядом:

Удобства использования git из консоли не всегда очевидно для тех, кто привык пользоваться графическим интерфейсом.

Соответственно, когда у вас есть доступ и к консоли, и к боковой панели, можете успешно использовать лучшее из обоих миров так, как будет удобно именно Вам.

Применительно к VS Code с установленным плагином GitLens хочу поделиться парочкой специфичных лайфхаков.

2. Конфиги, конфиги, конфиги. Разделяйте и властвуйте

(Upd. Как оказалось, есть ещё четвёртый уровень конфигов, специфичный для отдельных рабочих копий одного репозитория worktree. Подробнее про worktree см. ниже.)

Также в моей практике был случай, когда в рабочих репозиториях надо было пользоваться строго рабочей почтой, при этом в своих локальных репозиториях я продолжал пользоваться личной. Чтобы даже случайно нельзя было перепутать где что, я удалил user.name / email из глобального конфига, каждый раз указывая их заново в локальном, держа процесс под контролем.

3. Используйте временные коммиты вместо stash при переходе между ветками

Скорее всего, Вы сталкивались хотя бы раз с ситуацией, когда надо срочно переключиться с одной ветки на другую, бросив всё в разобранном состоянии. Очень вероятно, что Вы знаете про git stash (от англ. «тайник»), который позволяет «спрятать» Ваши текущие изменения. Однако во время его использования Вы можете столкнуться со следующими вещами:

А зачем тогда stash вообще нужен? Я предпочитаю их использовать для хранения мелких фиксов, которые нужны только для отладки и не должны быть закоммичены вообще. Есть возможность применять не только последний из стешей, но и вообще любой, ссылаясь на его имя. Самое большое удобство в том, что стеши хоть и «помнят» на какой ветке были сделаны, но ни к чему не обязывают и могут быть применены на любой ветке. Я где-то когда-то нашёл очень удобные алиасы для этого:

Пользователям Windows этот трюк иногда совершенно незнаком, а для пользователей Linux он может быть привычен по аналогичному использованию в bash :

5. Не клонируйте репозиторий, когда в этом нет нужды

Предположим, у вас есть две принципиально несовместимые друг с другом ветки — например, когда создаётся множество временных неотслеживаемых файлов кэша, при переходе между ветками можно замучиться их вычищать (передаю привет Unity).

Пришло задание срочно переключиться с одной на другую. Клонировать репозиторий вариант, но может занять уйму времени и места. Вычищать лишние файлы не вариант. На помощь приходит worktree : возможность держать несколько рабочих копий для одного репозитория. Из документации:

Клонирования не происходит, по сути просто чекаут в другую папку, которую потом можно оставить или не жалко удалить.

6. Применяйте pull только как fast-forward

На всякий случай, напоминаю, что pull по умолчанию делает fetch (выкачивание ветки с удалённого репозитория) и merge (слияние локальной и удалённой веток), а fast-forward — это режим слияния, когда нет никаких изменений в локальной ветке и происходит «перемотка» её на последний коммит из удалённой. Если изменения есть, то происходит классический мерж с ручным разрешением конфликтов и мерж-коммитом.

7. Скрывайте лишнее через git exclude

(Не забудьте подставить Ваш любимый редактор.)

8. Скрывайте локальные изменения, когда не хотите их «вливать»

Есть административный вариант решения проблемы: вынести все конфиги в отдельную папку, из которой каждый будет сам копировать конфиги в нужные места. И есть путь одиночки возможность заоверрайдить на месте и пометить файл как неизменённый:

9. Отслеживайте хаки локальные изменения в обход репозитория

Теперь немного чёрной магии. Предположим, что Вы не только изменили конфиги, но и хотите сохранить их в истории, чтобы помнить, почему Вы так сделали, и иметь возможность переключаться между разными версиями. Или же хотите отслеживать файлы, которые в принципе игнорируются главным репозиторием. Суть одна, в основной репозиторий заливать их нельзя. stash в этом может помочь, но когда разных изменений накапливается много, в них можно прострелить сломать ногу.

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

(для Windows это C:\Users\%USERNAME%\ ).

10. Используйте хуки

Про хуки много рассказано в других статьях, например и вот, но не упомянуть их нельзя. Благодаря git bash они одинаково работают как в Unix-like системах так и в Windows, правда, если они при этом запускают что-то ещё, можно огрести приключений. Полезны, например, хуки:

11. Требуйте автодополнение

Напоследок хочу сказать довольно банальную вещь — автодополнение существенно улучшает качество жизни. В большинстве Unix-систем оно идёт из коробки, но если Вас угораздило оказаться в инфраструктуре Windows — настоятельно рекомендую перейти на Powershell (если ещё не) и установить posh-git, который обеспечивает автодополнение большинства команд и даёт минималистичную сводку в prompt:

Спасибо за внимание; желаю всем приятной и эффективной каждодневной работы.

Бонус для внимательных. Упомянутые выше и несколько неупомянутых алиасов из конфига:

Источник