Как да откажем неопределени промени в Git?

Как да отмените промените в работното си копие, които не са изброени в индекса?

3956
09 сент. Задаване само за 9 септември. 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 Sep 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 сент. Отговорът е даден на Тоби 09 Сеп. 2008-09-09 22:37 '08 в 22:37 ч. 2008-09-09 22:37

Изглежда, че цялостното решение:

 git clean -df git checkout -- . 

git clean премахва всички необработени файлове ( предупреждение ), докато не изтрива игнорираните файлове, споменати директно в .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.06.09 в 13:28 2009-06-20 13:28
 git clean -df 

Почиства работното дърво чрез рекурсивно изтриване на файлове, които не са под контрола на версиите, като се започне с текущата директория.

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

-f : Force (може да не е необходимо в зависимост от настройката clean.requireForce )

Стартирайте git help clean да видите урока.

218
07 дек. Отговор, даден от Елвис Сиоти, 07 декември 2011-12-07 16:09 '11 в 16:09 2011-12-07 16:09

Моят любим

 git checkout -p 

Това ви позволява да избирателно връщате парчета.

Вижте също:

 git add -p 
85
10 окт. отговор, даден Бен 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 ще откаже да премахне файлове или директории, освен ако не -i зададена -f , -n или -i . Git ще откаже да изтрива директории в поддиректория или файл .git ако не е -f second -f .

-x

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

В допълнение, git checkout. трябва да се изпълнява в основата на репо.

68
28 апр. Отговор, даден от Martin G 28 Apr. 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 . Поръчка "обновява файловете в работното дърво според версията в индекса". Ако файловете не са били доставени (също са добавени към индекса) ... тази команда ще върне файловете до последното ви поправка.

    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 отговорът е даден от Джошуа Кунцман 28 юли '11 в 8:27 2011-07-28 08: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 отговорът е даден на Бижан 17 май, 14 в 5:28 2014-05-17 05: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

Вместо да отхвърля промените, рестартирам конзолата си в началото. Забележка. Този метод е предназначен за пълно възстановяване на папката, използвайки репо.

Ето защо, аз правя това, за да се уверя, че те не седят там, когато git reset (по-късно - изключва gitignores в Origin / branchname)

ЗАБЕЛЕЖКА. Ако искате файловете да не бъдат проследявани още, но не и в GITIGNORE, можете да пропуснете тази стъпка, тъй като това ще унищожи тези не-изкопаеми файлове, които не са намерени в отдалеченото хранилище (благодарение на @XtrmJosh).

 git add --all 

Тогава аз

 git fetch --all 

След това се връщам в началото

 git reset --hard origin/branchname 

Това ще го върне на площада. Точно като RE-клониране на клон, докато, съхраняване на всичките ми gitignored файлове локално и на място.

Актуализиран до потребителски коментар по-долу: Променете за нулиране за всеки текущ клон, на който е активиран потребителят.

 git reset --hard @{u} 
31
08 авг. Отговорът е даден Ник 08 авг. 2015-08-08 00:15 '15 в 0:15 2015-08-08 00:15

Ако просто искате да изтриете промени в съществуващи файлове , използвайте checkout ( документирано тук ).

 git checkout -- . 
  • Не е посочен клон, така че проверява текущия клон.
  • Двойното тире ( -- ) казва на Geeta, че следващото следващо трябва да се вземе за втория му аргумент (път), че сте пропуснали спецификацията на клона.
  • Период ( . ) Показва всички пътища.

Ако искате да изтриете файлове, добавени след последното финализиране, използвайте clean ( документирани тук ):

 git clean -i 
  • Опцията -i инициира интерактивно clean за предотвратяване на погрешни изтривания.
  • Има няколко други възможности за по-бързо изпълнение; вижте документацията.

Ако искате да преместите промените в пространство за съхранение за по-късен достъп , използвайте stash ( документирано тук ):

 git stash 
  • Всички промени ще бъдат прехвърлени в Git Stash за възможен последващ достъп.
  • Предлагат се няколко варианта за по-фино закачане; вижте документацията.
25
18 марта '18 в 3:19 2018-03-18 03:19 Отговорът е даден от jtheletter на 18 март'18 в 3:19 2018-03-18 03: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 . Но в този момент сте използвали по-добре (от Мариуш Новак):

 git checkout -- . git clean -df 

Въпреки това, аз харесвам git stash -u най-добре, защото "отхвърля" всички проследени и непроверени промени само в една команда. Все още се git checkout -- . само отхвърля проследените промени, а git clean -df отхвърля само git clean -df промени ... и въвеждането на двете команди е твърде много работа :)

20
08 сент. Отговор, даден от Ben Wilde Sep 08 2016-09-08 09:19 '16 в 9:19 2016-09-08 09:19

Той дори работи в директории; извън нормалните разрешения за git.

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

Това се случи наскоро

16
05 сент. Отговорът е даден от GlassGhost 05 Sep. 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 feb . 2016-02-05 03:59 '16 в 3:59 2016-02-05 03:59

Друг начин да се отървете от нови файлове, които са по-специфични от git clean -df (това ще ви позволи да се отървете от някои файлове, които не са задължително всички), е първо да добавите нови файлове към индекса, след това да ги скриете и след това да изпуснете кеша.

Този метод е полезен, когато по някаква причина не можете лесно да изтриете всички необработени файлове по някакъв обикновен механизъм (например 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 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

Това, което следва, е само решение, ако работите с хранилището, където редовно се синхронизирате (например заявка за прехвърляне) с друго репо. Краткият отговор е: премахнете вилицата и презаредете, но прочетете предупрежденията на 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 

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

Успях да реша проблема, като изтрих разклоненото си хранилище и всички местни хранилища и се върнах обратно. Само това не беше достатъчно; нагоре трябваше да преименува въпросните файлове в нови имена на файлове. Докато нямате счупена работа, няма уики и няма проблеми, които да се отклоняват от хранилището, трябва да сте добре. Най-малкото, Upstream може да не е много доволен от вас. Що се отнася до моя проблем, това несъмнено е потребителска грешка, тъй като не разполагам с този git опит, но фактът, че това не е лесно да се определи, показва проблем с git.

9
05 янв. Отговорът е даден от bbarker 05 jan. 2014-01-05 07:53 '14 в 7:53 ч. 2014-01-05 07: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 

[edit] както е коментирано, може да се нарича stashes. Е, използвайте това, ако искате да споделите портфейла си;)

7
08 июля '13 в 18:07 2013-07-08 18:07 Отговорът е даден на два пъти: Юли 08 '13 в 18:07 2013-07-08 18:07

Ако всички стъпка по стъпка файлове са действително фиксирани, тогава клонът може да бъде само нулиране, например. от вашия GUI с три кликвания на мишката: Vetka , Reset , Yes !

Следователно, това, което често правя на практика, за да отмените нежеланите локални промени, е да прехвърля всички добри неща и след това да възстановя клона.

Ако добрият материал е фиксиран в едно поемане, тогава можете да използвате "change last commit", за да го върнете към настройката или нестабилно, ако искате да го направите малко по-различно в края.

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

Така че аз просто се ангажира , клон рестартиране и промяна на последния ангажимент .

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.06.17 в 7:44 2017-06-05 07:44

Нито едно от решенията не работи, ако току-що промените разрешенията за файлове (това е DOS / Windoze)

 Пон 23/11 / 2015-15: 16: 34.80 C: ... \ t На клон SLF4J_1.5.3 Промените не са поставени за ангажимент:   (използвайте „git add ...“, за да актуализирате какво ще бъде извършено)   (използвайте „git checkout - ...“, за да отхвърлите промените в работната директория) модифициран: .gitignore модифициран: LICENSE.txt промяна: TODO.txt модифициран: codeStyle.xml модифициран: pom.xml модифициран: version.pl няма промени, добавени към поемането (използвайте „git add“ и / или „git commit -a“) Пон 23/11 / 2015-15: 16: 37.87 C: ... \ t diff - git a / .gitignore b / .gitignore стар режим 100644 нов режим 100755 diff - git a / LICENSE.txt b / LICENSE.txt стар режим 100644 нов режим 100755 diff - прибавете a / TODO.txt b / TODO.txt стар режим 100644 нов режим 100755 diff - git a / codeStyle.xml b / codeStyle.xml стар режим 100644 нов режим 100755 diff - git a / pom.xml b / pom.xml стар режим 100644 нов режим 100755 diff - git a / version.pl b / version.pl стар режим 100644 нов режим 100755 Mon 23/11 / 2015-15: 16: 45.22 C: ... \ t HEAD вече е на 8fa8488 12133-CHIXMISSINGMESSAGES MALCOLMBOEKHOFF 20141223124940 Добавен .gitignore Пон 23/11 / 2015-15: 16: 47.42 C: ... \ t Пон 23/11 / 2015-15: 16: 53.49 C: ... \ t Запазена работна директория и състояние на индекс WIP на SLF4J_1.5.3: 8fa8488 12133-CHIXMISSINGMESSAGES MALCOLMBOEKHOFF 20141223124940 Добавен .gitignore HEAD вече е на 8fa8488 12133-CHIXMISSINGMESSAGES MALCOLMBOEKHOFF 20141223124940 Добавен .gitignore Пон 23/11 / 2015-15: 17: 00.40 C: ... \ t Отказани refs / stash @ {0} (cb4966e9b1e9c9d8daa79ab94edc0c1442a294dd) Пон 23/11 / 2015-15: 17: 06.75 C: ... \ t Отказани refs / stash @ {0} (e6c49c470f433ce344e305c5b778e810625d0529) Пон 23/11 / 2015-15: 17: 08.90 C: ... \ t Не е намерено скривалище. Пон 23/11 / 2015-15: 17: 15.21 C: ... checkout slf4j +> git checkout -. Пон 23/11 / 2015-15: 22: 00.68 C: ... checkout sf4j +> git checkout -f -. Пон 23/11 / 2015-15: 22: 04.53 C: ... \ t На клон SLF4J_1.5.3 Промените не са поставени за ангажимент:   (използвайте „git add ...“, за да актуализирате какво ще бъде извършено)   (използвайте „git checkout - ...“, за да отхвърлите промените в работната директория) модифициран: .gitignore модифициран: LICENSE.txt промяна: TODO.txt модифициран: codeStyle.xml модифициран: pom.xml модифициран: version.pl няма промени, добавени към поемането (използвайте „git add“ и / или „git commit -a“) Пн 23/11 / 2015-15: 22: 13.06 C: ... \ t diff - git a / .gitignore b / .gitignore стар режим 100644 нов режим 100755 diff - git a / LICENSE.txt b / LICENSE.txt стар режим 100644 нов режим 100755 diff - прибавете a / TODO.txt b / TODO.txt стар режим 100644 нов режим 100755 diff - git a / codeStyle.xml b / codeStyle.xml стар режим 100644 нов режим 100755 diff - git a / pom.xml b / pom.xml стар режим 100644 нов режим 100755 diff - git a / version.pl b / version.pl стар режим 100644 нов режим 100755

Единственият начин да поправите това е ръчно възстановяване на разрешенията за модифицирани файлове:

 Пон 23/11 / 2015-15: 25: 43.79 C: ... визуализация sf4j +> git status -s |  egrep "^ M" |  разрез -c4- |  за / f "usebackq tokens = * delims ="% A в ("повече") направи chmod 644% ~ A Пон 23/11 / 2015-15: 25: 55.37 C: ... \ t На клон SLF4J_1.5.3 нищо за ангажиране, чиста работна директория Пн 23/11 / 2015-15: 25: 59.28 C: ... регистрация \ t Пон 23/11 / 2015-15: 26: 31.12 C: ... \ t
5
23 нояб. Отговорът е даден от Malcolm Boekhoff 23 ноември. 2015-11-23 07:30 '15 в 7:30 часа 2015-11-23 07:30 часа

Ако сте в случай на подмодул и не работят други решения, опитайте:

  • За да проверите какъв е проблемът (вероятно с мръсния случай), използвайте:

    git diff

  • За да премахнете скрития текст

    git submodule update

5
02 окт. отговорът е даден onalbi 02 oct. 2015-10-02 00:32 '15 в 0:32 2015-10-02 00:32

Имах странна ситуация, когато файлът винаги липсваше, помага ми да реша.

git rm.gitattributes
git add -A
git reset - твърд

5
08 февр. Отговорът е даден SDV 08 февруари. 2017-02-08 14:58 '17 в 14:58 часа 2017-02-08 14:58
  • 1
  • 2

Други въпроси относно tag или Ask a Question