Як вирішити git, кажучи: "Введіть свої зміни або схойте їх, перш ніж ви зможете об'єднатися"?

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

помилка: Ваші локальні зміни до таких файлів будуть перезаписані об'єднанням:

wp-content / w3tc-config / master.php

Будь ласка, введіть свої зміни або сховіть їх, перш ніж ви зможете об'єднатись.

Так я побіг,

git checkout -- wp-content/w3tc-config/master.php

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

Будь-які ідеї?

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

У вас є три варіанти:

• Здійсніть зміни, використовуючи

  git commit -m "My message"
  

• Заховай це.

  Stashing діє як стек, куди ви можете натиснути зміни, і ви переймете їх у зворотному порядку.

  Щоб приховати, введіть

  git stash
  

  Зробіть злиття, а потім витягніть скриньку:

  git stash pop
  

• Відмовтеся від місцевих змін

  за допомогою git reset --hard
  абоgit checkout -t -f remote/branch

  Або: Відкиньте локальні зміни для певного файлу

  використовуючи git checkout filename

git stash
git pull <remote name> <remote branch name> (or) switch branch
git stash apply --index

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

Друга команда перемикає гілки.

Третя команда відновлює зміни, які ви зберегли в сховищі ( --indexопція корисна, щоб переконатися, що поетапні файли все ще зберігаються).

Ви можете спробувати один із наступних методів:

ребаза

Для простих змін спробуйте перезавантажити поверх нього, потягнувши зміни, наприклад

git pull origin master -r

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

Це еквівалентно: checkout master, fetchі rebase origin/masterкоманда Git.

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

перевіряти

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

git checkout origin/master -f
git checkout master -f

скинути

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

git reset HEAD --hard

Якщо вище не допоможе, це можуть бути правила у вашому файлі нормалізації git ( .gitattributes), тож краще виконати те, що він говорить. Або ваша файлова система не підтримує дозволи, тому вам потрібно вимкнути filemodeконфігурацію git.

Пов'язане: Як змусити "git pull" перезаписати локальні файли?

Спробуйте це

git stash save ""

і спробуйте потягнути ще раз

Тож ситуація, в яку я зіткнувся, була така:

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

окрім того, безпосередньо перед цим було віддалено: так насправді це:

remote: error: Ваші локальні зміни до наступних файлів будуть перезаписані злиттям: some / file.ext Будь ласка, введіть свої зміни або схойте їх, перш ніж ви зможете об'єднатись.

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

Тож, що я закінчив, простеживши гачок після отримання та виявивши це, потрібно було перейти до віддаленого сховища на сервері, і там відбулася зміна (чого не було в моєму локальному сховищі, що, власне, сказав, що він збігався, ніяких змін, нічого не потрібно робити, до цього часу і т. д.) Тож, на локальному рівні не було змін на сервері, я потім зробив а, git checkout -- some/file.extа потім локальні та віддалені сховища насправді відповідали, і я міг продовжуйте працювати та розгортати. Не зовсім впевнений, як виникла така ситуація, хоча пару десятків розробників плюс зміни ІТ можуть мати щось із цим.

ПОПЕРЕДЖЕННЯ: Це видалить незатребувані файли, тому це не чудова відповідь на це питання.

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

Git 2.11 і новіші:

git clean  -d  -fx .

Старіші Git:

git clean  -d  -fx ""

Довідка: http://www.kernel.org/pub/software/scm/git/docs/git-clean.html

• -x означає, що ігноровані файли також видаляються, а також файли, невідомі для git.

• -d означає видалити не відстежувані каталоги на додаток до відслідковуваних файлів.

• -f потрібно, щоб змусити його працювати.

Щоб зберігати записи ваших новостворених файлів, вирішуючи цю проблему:

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

1. Поетапно змінюйте місцеві зміни. (не вчиняють). Потрібна постановка для створення виправлення нових створених файлів (оскільки вони ще не відстежуються)

git add .

2. Створіть виправлення для збереження запису

git diff --cached > mypatch.patch

3. Відкиньте локальні зміни та видаліть нові локальні файли

git reset --hard

4. Потягніть зміни

git pull

5. Нанесіть свій пластир

git apply mypatch.patch

Git об'єднає зміни та створить .rej-файли для змін, які не об'єднуються.

Як пропонує Ану, якщо у вас виникли проблеми із застосуванням виправлення, спробуйте:

git apply --reject --whitespace=fix mypatch.patch Ця відповідь git: patch не застосовує детально обговорити це питання

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

Просити взяти на себе зобов’язання перед витягненням

• git stash
• git pull origin << назва гілки >>

При необхідності :

• застосувати git stash

Для мене тільки git reset --hardпрацював.

Здійснення зобов’язань не було варіантом, оскільки не було чого робити.

Сшивання не було варіантом, тому що не було що приховувати.

Схоже, це могло бути з виключених файлів у .git/info/excludeта git update-index --assume-unchanged <file>редагуванні деяких файлів.

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

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

Це, ймовірно, викликано проблемами CRLF.

Дивіться: Чому я повинен використовувати core.autocrlf = true у Git?

Використовуйте це, щоб витягнути та примусити оновити:

git pull origin master
git checkout origin/master -f

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

і повідомлення про помилку остаточно зникло:

1: git add .

2: git commit -m "this is an additional commit"

3: git checkout the-other-file-name

тоді це спрацювало. сподіваюся, що ця відповідь допоможе. :)

Якщо ви використовуєте розширення Git, ви маєте змогу знайти ваші локальні зміни у Working directoryнаведеному нижче:

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

Коли ви знайшли якісь неспроможні зміни:

Виберіть рядок з Working directory, перейдіть на Diff вкладці правою кнопкою миші по рядках з олівцем (або +чи -значок), виберіть Скидання в першу здійснити або вчиняє чи притон або що ви хочете з ним робити.

Для мене це спрацювало:

git reset --hard

і потім

git pull origin <*current branch>

після того

git checkout <*branch>

мабуть

git --rebase --autostash

допомогло б