Як відмовитися від невстановлених змін в Git?

Як скасувати зміни в моїй робочій копії, які не вказані в індексі?

3956
09 сент. заданий Readonly 09 сент. 2008-09-09 22:33 '08 о 22:33 2008-09-09 22:33
@ 32 відповідей
  • 1
  • 2

Ще один швидкий спосіб:

 git stash save --keep-index --include-untracked 

Вам не потрібно включати --include-untracked якщо ви не хочете бути --include-untracked .

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

2225
09 сент. відповідь дан Greg Hewgill 09 сент. 2008-09-09 22:39 '08 о 22:39 2008-09-09 22:39

Для всіх невстановлених файлів використовуйте:

 git checkout -- . 

Для конкретного використання файлу:

border=0
 git checkout path/to/file/to/revert 

Обов'язково вкажіть період в кінці.

4303
09 сент. відповідь дан Tobi 09 сент. 2008-09-09 22:37 '08 о 22:37 2008-09-09 22:37

Схоже, що повне рішення:

 git clean -df git checkout -- . 

git clean видаляє всі необроблені файли (warning), в той час як він не видаляє ігноровані файли, згадані безпосередньо в .gitignore, він може видалити проігноровані файли, що знаходяться в папках), а git checkout очищає все невстановлені зміни.

1643
29 авг. відповідь дан Mariusz Nowak 29 Серпня. 2012-08-29 21:28 '12 о 21:28 2012-08-29 21:28

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

 git checkout . 

або це, яке перевіряє всі файли з індексу, переписуючи робочі файли дерева.

 git checkout-index -a -f 
283
20 июня '09 в 13:28 2009-06-20 13:28 відповідь дан CB Bailey 20 червня '09 о 13:28 2009-06-20 13:28
 git clean -df 

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

-d : видалити непотрібні каталоги на додаток до файлів без сліду

-f : Сила (може бути необов'язкова в залежності від настройки clean.requireForce )

Запустіть git help clean , щоб переглянути керівництво

218
07 дек. відповідь дан Elvis Ciotti 07 дек. 2011-12-07 16:09 '11 о 16:09 2011-12-07 16:09

Мій улюблений

 git checkout -p 

Це дозволяє вибірково повертати шматки.

Див. також:

 git add -p 
85
10 окт. відповідь дан Ben 10 Жовтня. 2014-10-10 15:31 '14 о 15:31 2014-10-10 15:31

Оскільки ніякої відповіді не пропонує точного варіанта комбінації, яку я використовую, ось він:

 git clean -dfx git checkout . 

Це текст довідки для використовуваних опцій git clean :

-d

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

-f

Якщо змінна конфігурації Git clean.requireForce не встановлена в значення false , Git clean відмовиться видалити файли або каталоги, якщо не вказано -f , -n або -i . Git відмовиться від видалення каталогів в підкаталозі .git або файлі, якщо не -f другий -f .

-x

Не використовуйте правила ігнорування з .gitignore (для кожного каталогу) і $GIT_DIR/info/exclude , але все одно використовуйте правила ігнорування, задані з параметрами -e . Це дозволяє видалити всі необроблені файли, включаючи збірку продуктів. Це можна використовувати (можливо, в поєднанні з git reset ), щоб створити незайманий робочий каталог для перевірки чистої збірки.

Крім того, git checkout. необхідно виконати в корені репо.

68
28 апр. відповідь дан Martin G 28 Квітня. 2016-04-28 22:46 '16 о 22:46 2016-04-28 22:46

Я дійсно знайшов цю статтю корисною для пояснення, коли використовувати яку команду: http://www.szakmeister.net/blog/2011/oct/12/reverting-changes-git/

Є кілька різних випадків:

  • Якщо ви не поставили файл, використовуйте git checkout . Checkout "оновлює файли в робочому дереві відповідно до версії в індексі". Якщо файли не були поставлені (також додані в індекс) ... ця команда по суті поверне файли до того, що було вашим останнім фіксатором.

    git checkout -- foo.txt

  • Якщо ви поставили файл, використовуйте git reset. Reset змінює індекс відповідно до фіксацією.

    git reset -- foo.txt

Я підозрюю, що використання git stash є популярним вибором, оскільки він трохи менш небезпечний. Ви завжди можете повернутися до нього, якщо ви випадково видаліть дуже багато при використанні git reset. Reset за замовчуванням рекурсивний.

Погляньте на статтю вище, щоб отримати додаткові поради.

53
14 авг. відповідь дан blak3r 14 Серпня. 2012-08-14 00:31 '12 в 0:31 2012-08-14 00:31

Найпростіший спосіб зробити це - використовувати цю команду:

Ця команда використовується для скасування змін до робочому каталозі -

 git checkout -- . 

https://git-scm.com/docs/git-checkout

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

 git stash -u 

http://git-scm.com/docs/git-stash

45
12 апр. відповідь дан AHM Forhadul Islam 12 Квітня. 2017-04-12 12:27 '17 о 12:27 2017-04-12 12:27

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

 git diff | git apply --reverse 
41
28 июля '11 в 8:27 2011-07-28 08:27 відповідь дан Joshua Kunzmann 28 липня '11 о 8:27 2011-07-28 8:27

Під час введення статусу git (використовуйте "git checkout -...", щоб скасувати зміни в робочому каталозі).

наприклад. git checkout -- .

39
17 мая '16 в 14:27 2016-05-17 14:27 відповідь дан Erdem ÖZDEMİR 17 травня '16 о 14:27 2016-05-17 14:27

git checkout -f


man git-checkout :

-f, --force

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

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

38
17 мая '14 в 5:28 2014-05-17 05:28 відповідь дан Bijan 17 травня '14 в 5:28 2014-05-17 5:28

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

 git add . git stash 

якщо ви перевірите, що все в порядку, відкиньте тайник:

 git stash drop 

Відповідь від Bilal Maqsood за допомогою git clean також працював на мене, але з додатком у мене більше контролю - якщо я випадково зроблю це, я все одно можу повернути свої зміни

UPDATE

Я думаю, що є ще одна зміна (не знаю, чому це спрацювало для мене раніше):

git add . -A git add . -A замість git add .

без -A віддалені файли не будуть розміщені

33
11 сент. відповідь дан Asped 11 сент. 2015-09-11 14:59 '15 о 14:59 2015-09-11 14:59

Замість відкидання змін я reset мій пульт в початок. Примітка. Цей метод призначений для повного відновлення вашої папки за допомогою репо.

Тому я роблю це, щоб переконатися, що вони не сидять там, коли я git reset (пізніше - виключає gitignores в Origin / branchname)

ПРИМІТКА. Якщо ви хочете, щоб файли ще не відстежувалися, але не в GITIGNORE, ви можете пропустити цей крок, тому що він знищить ці невикопного файли, які не знайдені в віддаленому репозиторії (спасибі @XtrmJosh).

 git add --all 

тоді I

 git fetch --all 

Тоді я reset в початок

 git reset --hard origin/branchname 

Це поверне його до квадрату. Точно так же, як RE-клонування гілки, WHILE, зберігаючи всі мої gitignored файли локально і на місці.

Оновлене на коментар користувача нижче: Зміна до reset для будь-якої поточної гілки, на якій користувач включений.

 git reset --hard @{u} 
31
08 авг. відповідь дан Nick 08 Серпня. 2015-08-08 00:15 '15 в 0:15 2015-08-08 00:15

Якщо ви просто хочете видалити зміни в існуючі файли, використовуйте checkout ( задокументовано тут ).

 git checkout -- . 
  • Ніяка гілка не вказана, тому вона перевіряє поточну гілку.
  • Подвійний дефіс ( -- ) говорить Гіт, що наступне слід прийняти за його другий аргумент (шлях), що ви пропустили специфікацію гілки.
  • Період ( . ) Вказує всі шляхи.

Якщо ви хочете видалити файли, додані з моменту останнього коммітов, використовуйте clean ( задокументовано тут ):

 git clean -i 
  • Параметр -i ініціює інтерактивну clean , щоб запобігти помилкові видалення.
  • Для більш швидкого виконання є кілька інших опцій; см. документацію.

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

 git stash 
  • Всі зміни будуть перенесені в Git Stash для можливого подальшого доступу.
  • Кілька варіантів доступні для більш тонкого stashing; см. документацію.
25
18 марта '18 в 3:19 2018-03-18 03:19 відповідь дан jtheletter 18 березня '18 о 3:19 2018-03-18 3:19

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

Використовуйте git clean -f , щоб видалити ці нові файли - з обережністю! Зверніть увагу на параметр сили.

25
15 окт. відповідь дан artur 15 Жовтня. 2011-10-15 00:07 '11 в 0:07 2011-10-15 00:07

просто скажіть

 git stash 

Він видалить всі ваші локальні зміни. Ви також можете використовувати пізніше, кажучи

 git stash apply 

або git stash pop

20
24 апр. відповідь дан piyushmandovra 24 Квітня. 2015-04-24 15:19 '15 о 15:19 2015-04-24 15:19

Просто використовуйте:

 git stash -u 

Готово. Легко.

Якщо ви дійсно дбаєте про своє стешевом стеку, ви можете слідувати за допомогою git stash drop . Але в цей момент вам краще використовувати (від Mariusz Nowak):

 git checkout -- . git clean -df 

Проте, мені подобається git stash -u краще, тому що він "відкидає" всі відслідковують і не перевірені зміни тільки в одній команді. Проте git checkout -- . тільки відкидає відслідковують зміни, і git clean -df тільки відкидає невідтворювані зміни ... і введення обох команд - це занадто багато роботи :)

20
08 сент. відповідь дан Ben Wilde 08 сент. 2016-09-08 09:19 '16 в 9:19 2016-09-08 9:19

Це працює навіть в каталогах; поза нормальних дозволів git.

 sudo chmod -R 664 ./*  git checkout -- .  git clean -dfx 

Сталося недавно недавно

16
05 сент. відповідь дан GlassGhost 05 сент. 2013-09-05 12:38 '13 в 12:38 2013-09-05 12:38
 cd path_to_project_folder # take you to your project folder/working directory git checkout . # removes all unstaged changes in working directory 
14
30 мая '14 в 12:26 2014-05-30 12:26 відповідь дан vivekporwal04 30 травня '14 о 12:26 2014-05-30 12:26

Незалежно від того, в якому стані ваше репо знаходиться, ви завжди можете скинути всі попередні фіксації:

 git reset --hard <commit hash> 

Це скасує всі зміни, які були зроблені після цього фіксації.

10
05 февр. відповідь дан msangel 05 февр. 2016-02-05 03:59 '16 о 3:59 2016-02-05 3:59

Інший спосіб позбутися від нових файлів, більш специфічних, ніж git clean -df (він дозволить вам позбавитися від деяких файлів не обов'язково всіх), полягає в тому, щоб спочатку додати нові файли в індекс, потім stash, потім відкиньте тайник.

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

10
15 июня '12 в 11:55 2012-06-15 11:55 відповідь дан tjb 15 червня '12 об 11:55 2012-06-15 11:55

По-моєму,

 git clean -df 

повинен зробити трюк. Згідно Git документації по git clean

git -clean - видалити необроблені файли з робочого дерева

опис

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

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

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

Опції

-d Видаліть непотрібні каталоги на додаток до файлів без сліду. Якщо непідписаний каталог управляється іншим репозиторієм git, це не видаляється за замовчуванням. Використовуйте параметр -f двічі, якщо ви дійсно хочете видалити такий каталог.

-f --force Якщо змінна конфігурації git clean.requireForce не встановлена ​​в false, git clean відмовиться запускатися, якщо не задано -f, -n або -i.

9
14 июля '16 в 10:03 2016-07-14 10:03 відповідь дан Lahiru 14 липня '16 о 10:03 2016-07-14 10:03

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

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

Я б часто мав повідомлення про статус git, подібні до цього (за участю не менше 2/4 файлів):

 $ git status # Not currently on any branch. # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: doc/PROJECT/MEDIUM/ATS-constraint/constraint_s2var.dats # modified: doc/PROJECT/MEDIUM/ATS-constraint/parsing/parsing_s2var.dats # # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: doc/PROJECT/MEDIUM/ATS-constraint/constraint_s2Var.dats # modified: doc/PROJECT/MEDIUM/ATS-constraint/parsing/parsing_s2Var.dats 

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

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

9
05 янв. відповідь дан bbarker 05 Січня. 2014-01-05 07:53 '14 в 7:53 2014-01-05 7:53

Якщо ви хочете перенести чек на кого-то другого:

 # add files git add . # diff all the changes to a file git diff --staged > ~/mijn-fix.diff # remove local changes git reset  git checkout . # (later you can re-apply the diff:) git apply ~/mijn-fix.diff 

[Ред], як прокоментовано, можна назвати stashes. Добре, використовуйте це, якщо хочете поділитися своїм гаманцем;)

7
08 июля '13 в 18:07 2013-07-08 18:07 відповідь дан twicejr 08 липня '13 о 18:07 2013-07-08 18:07

Якщо все поетапні файли були фактично зафіксовані, то гілка може бути просто reset, наприклад. з вашого графічного інтерфейсу з трьома клацаннями миші: Гілка, Reset, Так!

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

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

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

Таким чином, я просто роблю commit, гілка reset і змінити останню фіксацію.

6
20 марта '15 в 18:38 2015-03-20 18:38 відповідь дан user3070485 20 березня '15 о 18:38 2015-03-20 18:38

Ви можете створити свій власний псевдонім, який описує, як це зробити описовим чином.

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


Скасувати зміни в (списку) файлу (ів) в робочому дереві

 discard = checkout -- 

Потім ви можете використовувати його для видалення всіх змін:

 discard . 

Або просто файл:

 discard filename 

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

Очистити і скасувати зміни і не відстежувати файли в робочому дереві

 cleanout = !git clean -df  git checkout -- . 

Тому використання просте:

 cleanout 

Тепер є в наступному репозиторії Github, який містить багато псевдонімів:

5
05 июня '17 в 7:44 2017-06-05 07:44 відповідь дан Pau 05 червня '17 о 7:44 2017-06-05 7:44

Жодне з рішень не працює, якщо ви просто змінили дозволу файлу (це на DOS / Windoze)

 Mon 23/11 / 2015-15: 16: 34.80 C: \ ... \ work \ checkout \ slf4j +> git status On branch SLF4J_1.5.3 Changes not staged for commit:   (Use "git add ..." to update what will be committed)   (Use "git checkout - ..." to discard changes in working directory) modified: .gitignore modified: LICENSE.txt modified: TODO.txt modified: codeStyle.xml modified: pom.xml modified: version.pl no changes added to commit (use "git add" and / or "git commit -a") Mon 23/11 / 2015-15: 16: 37.87 C: \ ... \ work \ checkout \ slf4j +> git diff diff --git a / .gitignore b / .gitignore old mode 100644 new mode 100755 diff --git a / LICENSE.txt b / LICENSE.txt old mode 100644 new mode 100755 diff --git a / TODO.txt b / TODO.txt old mode 100644 new mode 100755 diff --git a / codeStyle.xml b / codeStyle.xml old mode 100644 new mode 100755 diff --git a / pom.xml b / pom.xml old mode 100644 new mode 100755 diff --git a / version.pl b / version.pl old mode 100644 new mode 100755 Mon 23/11 / 2015-15: 16: 45.22 C: \ ... \ work \ checkout \ slf4j +> git reset --hard HEAD HEAD is now at 8fa8488 12133-CHIXMISSINGMESSAGES MALCOLMBOEKHOFF 20141223124940 Added .gitignore Mon 23/11 / 2015-15: 16: 47.42 C: \ ... \ work \ checkout \ slf4j +> git clean -f Mon 23/11 / 2015-15: 16: 53.49 C: \ ... \ work \ checkout \ slf4j +> git stash save -u Saved working directory and index state WIP on SLF4J_1.5.3: 8fa8488 12133-CHIXMISSINGMESSAGES MALCOLMBOEKHOFF 20141223124940 Added .gitignore HEAD is now at 8fa8488 12133-CHIXMISSINGMESSAGES MALCOLMBOEKHOFF 20141223124940 Added .gitignore Mon 23/11 / 2015-15: 17: 00.40 C: \ ... \ work \ checkout \ slf4j +> git stash drop Dropped refs / stash @ {0} (cb4966e9b1e9c9d8daa79ab94edc0c1442a294dd) Mon 23/11 / 2015-15: 17: 06.75 C: \ ... \ work \ checkout \ slf4j +> git stash drop Dropped refs / stash @ {0} (e6c49c470f433ce344e305c5b778e810625d0529) Mon 23/11 / 2015-15: 17: 08.90 C: \ ... \ work \ checkout \ slf4j +> git stash drop No stash found. Mon 23/11 / 2015-15: 17: 15.21 C: \ ... \ work \ checkout \ slf4j +> git checkout -. Mon 23/11 / 2015-15: 22: 00.68 C: \ ... \ work \ checkout \ slf4j +> git checkout -f -. Mon 23/11 / 2015-15: 22: 04.53 C: \ ... \ work \ checkout \ slf4j +> git status On branch SLF4J_1.5.3 Changes not staged for commit:   (Use "git add ..." to update what will be committed)   (Use "git checkout - ..." to discard changes in working directory) modified: .gitignore modified: LICENSE.txt modified: TODO.txt modified: codeStyle.xml modified: pom.xml modified: version.pl no changes added to commit (use "git add" and / or "git commit -a") Mon 23/11 / 2015-15: 22: 13.06 C: \ ... \ work \ checkout \ slf4j +> git diff diff --git a / .gitignore b / .gitignore old mode 100644 new mode 100755 diff --git a / LICENSE.txt b / LICENSE.txt old mode 100644 new mode 100755 diff --git a / TODO.txt b / TODO.txt old mode 100644 new mode 100755 diff --git a / codeStyle.xml b / codeStyle.xml old mode 100644 new mode 100755 diff --git a / pom.xml b / pom.xml old mode 100644 new mode 100755 diff --git a / version.pl b / version.pl old mode 100644 new mode 100755

Єдиний спосіб виправити це - вручну reset дозволу на змінені файли:

 Mon 23/11 / 2015-15: 25: 43.79 C: \ ... \ work \ checkout \ slf4j +> git status -s |  egrep "^ M" |  cut -c4- |  for / f "usebackq tokens = * delims ="% A in ( `more`) do chmod 644% ~ A Mon 23/11 / 2015-15: 25: 55.37 C: \ ... \ work \ checkout \ slf4j +> git status On branch SLF4J_1.5.3 nothing to commit, working directory clean Mon 23/11 / 2015-15: 25: 59.28 C: \ ... \ work \ checkout \ slf4j +> Mon 23/11 / 2015-15: 26: 31.12 C: \ ... \ work \ checkout \ slf4j +> git diff
5
23 нояб. відповідь дан Malcolm Boekhoff 23 нояб. 2015-11-23 07:30 '15 о 7:30 2015-11-23 7:30

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

  • Щоб перевірити, в чому проблема (можливо, "брудний" випадок), використовуйте:

    git diff

  • Щоб видалити прихований текст

    git submodule update

5
02 окт. відповідь дан onalbi 02 Жовтня. 2015-10-02 00:32 '15 в 0:32 2015-10-02 00:32

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

git rm.gitattributes
git add -A
git reset --hard

5
08 февр. відповідь дан SDV 08 февр. 2017-02-08 14:58 '17 о 14:58 2017-02-08 14:58
  • 1
  • 2

Інші питання по мітці або Задайте питання