Як адмовіцца ад неўстаноўленых змяненняў у 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 00:27

Калі вам не цікава захоўваць неўпаўнаважаныя змены (асабліва калі паэтапныя змены з'яўляюцца новымі файламі), я знайшоў гэта зручным:

 git diff | git apply --reverse 
41
28 июля '11 в 8:27 2011-07-28 08:27 адказ дадзены Joshua Kunzmann 28 ліпеня '11 ў 08: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 адказ дадзены Bijan 17 мая '14 у 05: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

Замест адкідвання змен я 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 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 . Але ў гэты момант вам лепш выкарыстоўваць (ад 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 у 09:19 2016/09/08 09: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 00: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 00:26

Незалежна ад таго, у якім стане ваша РЭПО знаходзіцца, вы заўсёды можаце скінуць ўсе папярэднія фіксацыі:

 git reset --hard <commit hash> 

Гэта адменіць усе змены, якія былі зробленыя пасля гэтага фіксацыі.

10
05 февр. адказ дадзены msangel 05 февр. 2016-02-05 03:59 '16 у 3:59 2016/02/05 03: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 у 07: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 

[Правіць], як пракаментавана, можна назваць 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 у 07:44 2017/06/05 07: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 07: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

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