Питання Як скасувати "git add" перед здійсненням?


Я помилково додав файли до git за допомогою команди:

git add myfile.txt

Я ще не бігаю git commit. Чи є спосіб скасувати це, так що ці файли не будуть включені в причетність?


На сьогодні існує 48 відповідей (деякі видалені). Будь ласка, не додавайте новий, якщо у вас немає нової інформації.


7463
2017-12-07 21:57


походження


Починаючи з Git v1.8.4, всі відповіді, які використовуються нижче HEAD або headтепер можна використовувати @ замість HEAD замість цього. Побачити ця відповідь (останній розділ) щоб дізнатись, чому ти можеш це зробити.
Я зробив невеликий підсумок, який показує всі способи не завантажити файл: stackoverflow.com/questions/6919121/... - Daniel Alder
Чому б не замовити GIT? - Erik Reppen
@ErikReppen git checkout не видаляє поетапні зміни з індексу фіксації. Це лише повертає нестандартні зміни до останньої внесеної версії - що, до речі, не те, що я хочу, я хотів би цих змін, я просто хочу їх у подальшому здійсненні. - paxos1977
Якщо ви використовуєте Eclipse, це настільки ж просто, як зняття прапорцями файлів у діалоговому вікні commit - Hamzahfrq


Відповіді:


Ви можете скасувати git add перед тим, як взяти з собою

git reset <file>

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

Ви можете використовувати

git reset

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

У старих версіях Git вказані вище команди еквівалентні git reset HEAD <file> і git reset HEAD відповідно, і не зможе, якщо HEAD це невизначено (тому що ви ще не зробили жодних зобов'язань у своєму репо) або неоднозначне (оскільки ви створили філію під назвою HEAD, це дурна річ, яку не слід робити). Це було змінено в Git 1.8.2, правда, так і в сучасних версіях Git ви можете скористатись вищезазначеними командами ще до того, як зробите першу фіксацію:

"git reset" (без параметрів або параметрів), який використовувався для виведення помилок коли      у вас немає жодних домовленостей у вашій історії, але тепер вона дає вам      порожній індекс (для того, щоб відповідати неіснуючому примусу, якого ви ще не маєте).


8377
2017-12-07 22:30



Звичайно, це не справжня скасування, бо якщо це неправильно git add переписав попередню поетапну незавершену версію, ми не можемо її відновити. Я намагався прояснити це в моїй відповіді нижче. - leonbloy
git reset HEAD *.ext де ext це файли даного розширення, яке ви хочете об'єднати. Для мене це було *.bmp & *.zip - boulder_ruby
@ Джонні, містить індекс (ака посередницька область) все файли, а не просто змінені файли. Він "запускає життя" (коли ви перевіряєте копію чи клон репо) як копію всіх файлів у фіксації, вказаному HEAD. Так що якщо ти видалити файл з індексу (git rm --cached), це означає, що ви готуєтесь зробити це видаляє цей файл git reset HEAD <filename> а з іншого боку копіює файл з HEAD до індексу, так що наступний внесок не покаже жодних змін у цьому файлі. - Wildcard
Я просто виявив, що існує а git reset -p так як git add -p. Це круто! - donquixote
Ти насправді може відновити перезаписані попередньо встановлені, але незавершені зміни але не зручним способом, а не 100% безпечним (принаймні нічого, що я його знайшов): goto .git / objects, пошук файлів, створених на момент git add ви хочете відновити (61/3AF3... -> ідентифікатор об'єкта 613AF3...), потім git cat-file -p <object-id> (може бути, це коштує, щоб відновити декілька годин роботи, а також уроку, щоб робити частіше ...) - Peter Schneider


Ти хочеш:

git rm --cached <added_file_to_undo>

Міркування:

Коли я був новим, я спочатку спробував

git reset .

(щоб відмінити весь початковий додаток), щоб отримати це (не так) корисне повідомлення:

fatal: Failed to resolve 'HEAD' as a valid ref.

Виявляється, це пов'язано з тим, що HEAD ref (branch?) Не існує лише після першого здійснення. Тобто ви будете стикатися з тією самою проблемою для початківців, як і я, якщо ваш робочий процес, як і моє, був щось на кшталт:

  1. cd до мого чудового нового каталогу проектів, щоб випробувати Git, нову горячу
  2. git init
  3. git add .
  4. git status

    ... багато прокрутки дербі ...

    => Чорт, я не хотів додати все це.

  5. google "скасувати додавання git"

    => знайти переповнення стеків - ой раз

  6. git reset .

    => смертельний: не вдалося вирішити "HEAD" як дійсне посилання.

Далі виявляється, що є помилка зареєстрована проти непотрібності цього в списку розсилки.

І це було правильним рішенням у випуску статусу Git (який, так, я глянсував як "crap")

...
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
...

І рішення дійсно є використанням git rm --cached FILE.

Зверніть увагу на попередження в іншому місці тут - git rm видаляє вашу локальну робочу копію файлу, але ні якщо ви використовуєте - кешована. Ось результат git help rm:

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

Я перейду до використання

git rm --cached .

щоб видалити все і почати знову. Не працював, хоча, поки add . є рекурсивним, виходить rm потреби -r повторювати Зітхає

git rm -r --cached .

Добре, тепер я повернувся туди, де я почав. Наступного разу я збираюся використовувати -n зробити сухе пробіг і подивитися, що буде додано:

git add -n .

Перш ніж довіряти, я застебнув все в безпечне місце git help rm про --cached нічого не руйнуючи (а що, якщо я це неправильно напишу).


1952
2018-03-25 16:20



Ха-ха Я дотримувався цього самого процесу. Крім того, я здався і сказав rm -rf .git, git init тому що я не довіряв git rm --cached зберегти мою робочу копію. Це трохи говорить про те, що деякі місця в деяких місцях занадто складні. git unstage повинен просто бути стандартною командою, мені все одно, чи можу я додати його як псевдонім. - Adrian Macneil
Для мене гіт каже git reset HEAD <File>... - drahnr
git rm --cached <file> є насправді правильною відповіддю, якщо це первинний імпорт <file> у репозиторій. Якщо ви намагаєтеся не опублікувати зміни у файлі, правильна відповідь - це скидання git. Люди, які кажуть, що ця відповідь не так, думають про інше питання. - Barry Kelly
Це дійсно буде працювати, але тільки на першій фіксації, де файл раніше не існував, або де git add команда додала нові файли але ні зміни до існуючих файлів. - naught101
просто йде, щоб показати, наскільки неінфункціональний і звивистий гіт. замість паралельних "скасувати" команд, ви повинні з'ясувати, як їх скасувати. Любіть намагатися звільнити ногу в швидкому пісі, а потім отримати руку застрягли, а потім отримати іншу руку застряг ... кожна команда повинна бути зроблена через графічний інтерфейс, зі спадними меню пунктів для опцій ... Подумайте про всі інтерфейсу, ми маємо продуктивність, але у нас є безлад інтерфейсу командного рядка retro. Це не схоже на програми GUI GUI, які роблять це інтуїтивно зрозумілим. - ahnbizcad


Якщо ви вводите:

git status

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

use "git reset HEAD <file>..." to unstage

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

Примітка. Останні версії Git (1.8.4.x) змінили це повідомлення:

(use "git rm --cached <file>..." to unstage)

484
2017-12-07 23:22



Повідомлення буде різним в залежності від того, чи є addED файл вже відстежувався ( add лише зберегла нову версію в кеш-пам'яті - тут буде показано ваше повідомлення). В іншому місці, якщо файл раніше не був встановлений, він буде відображатися use "git rm --cached <file>..." to unstage - leonbloy
Чудово! The git reset HEAD <file> один - єдиний, який буде працювати, якщо ви хочете не завантажити файл видалення - skerit
Моя версія Git 2.14.3 говорить git reset HEAD щоб не встигнути - seaturtle


Щоб уточнити: git add переміщує зміни з поточного робочого каталогу на оздоровчий майданчик (індекс).

Цей процес називається постановка. Отже, найбільш природне командування для етап зміни (зміни файлів) є очевидними:

git stage

git add просто легше вводити псевдонім для git stage

Жаль немає git unstage ні git unadd команди. Відповідний складніше вгадати або запам'ятати, але це досить очевидно:

git reset HEAD --

Ми можемо легко створити псевдонім для цього:

git config --global alias.unadd 'reset HEAD --'
git config --global alias.unstage 'reset HEAD --'

І, нарешті, у нас є нові команди:

git add file1
git stage file2
git unadd file2
git unstage file1

Особисто я використовую ще коротші псевдоніми:

git a #for staging
git u #for unstaging

220
2017-09-10 20:28



"рухається"? Це означатиме, що він вийшов з робочого каталогу. Це не справа. - Thomas Weller
Чому це очевидно? - Lenar Hoyt


Додатково до прийнятої відповіді, якщо ваш помилково доданий файл був величезний, ви, ймовірно, помітите це, навіть після того, як видалити його з індексу з "git reset', все ще, здається, займає простір у .git каталог Це не викликає занепокоєння. Файл, як і раніше, зберігається в сховищі, але лише як «вільний об'єкт», його не буде скопійовано в інші сховища (через клон, push), і простір буде остаточно відновлений - хоча можливо, не дуже скоро. Якщо ви занепокоєні, можете запустити:

git gc --prune=now

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

Так, що є справжнім скасувати від git add?

git reset HEAD <file> ?

або

git rm --cached <file>?

Строго кажучи, і якщо я не помиляюся: ніхто.

git add  не може бути скасовано - безпечно, взагалі.

Давайте спочатку згадати що git add <file> насправді робить:

  1. Якщо <file> був не раніше відстежуваних, git add  додає до кеша, з його поточним змістом.

  2. Якщо <file> був вже простежено, git add  зберігає поточний вміст (знімок, версія) в кеш. У GIT ця дія ще називається додати(не просто оновлення це), оскільки дві різні версії (знімки) файлу розглядаються як два різних пункти: отже, ми дійсно додаємо новий елемент до кешу, який в кінцевому підсумку буде призначений пізніше.

У світлі цього питання є дещо неоднозначним:

Я помилково додав файли за допомогою команди ...

Сценарій OP, як видається, є першим (не відстежуваний файл), ми хочемо, щоб "скасувати" видалити файл (а не тільки поточний вміст) з відслідковуваних елементів. Якщо це так, то добре бігти git rm --cached <file>.

І ми могли б також бігти git reset HEAD <file>. Це в цілому краще, оскільки воно працює в обох сценаріях: це також робить скасування, коли ми помилково додали версію вже відстеженого елемента.

Але є два застереження.

По-перше: існує (як зазначено у відповідь) лише один сценарій, в якому git reset HEAD не працює, але git rm --cached робить: новий репозиторій (не робить). Але, дійсно, це практично несуттєвий випадок.

Другий: майте на увазі це git reset HEAD  неможливо магічно відновити вміст попередньо кешованого файлу, він просто перезаписує його з HEAD. Якщо наш помилковий git add переписав попередню поставлену невиконану версію, ми не можемо її відновити. Ось чому, строго кажучи, ми не можемо скасувати.

Приклад:

$ git init
$ echo "version 1" > file.txt
$ git add file.txt   # first add  of file.txt
$ git commit -m 'first commit'
$ echo "version 2" > file.txt
$ git add  file.txt   # stage (don't commit) "version 2" of file.txt
$ git diff --cached file.txt
-version 1
+version 2
$ echo "version 3" > file.txt   
$ git diff  file.txt
-version 2
+version 3
$ git add  file.txt    # oops we didn't mean this
$ git reset HEAD file.txt  # undo ?
$ git diff --cached file.txt  # no dif, of course. stage == HEAD
$ git diff file.txt   # we have lost irrevocably "version 2"
-version 1
+version 3

Звичайно, це не дуже критично, якщо ми просто дотримуємося звичайного ленивого робочого процесу, що робить "git add" лише для додавання нових файлів (справа 1), і ми оновлюємо нове вміст через commit, git commit -a команда


137
2018-05-18 18:05



Строго кажучи, є спосіб відновити вже поставлений файл, який був замінений git add. Як ви згадаєте, git add створює об'єкт git для цього файлу, який стане вільним об'єктом не тільки при видаленні файлу повністю, але й при перезаписанні новим вмістом. Але немає команди, щоб автоматично його відновити. Замість цього файл повинен бути ідентифікований і витягнутий вручну або за допомогою інструментів, написаних лише для цього випадку (це дозволить libgit2). Але це буде виплачувати тільки, якщо файл є дуже важливим та великим, і його неможливо відновити, відредагувавши попередню версію. - Johannes Matokic
Щоб виправити себе: як тільки знайдено об'єктний файл (використовуйте мета-дані, такі як дата та час створення) git cat-file може бути використаний для відновлення свого контенту. - Johannes Matokic
Інший спосіб відновлювати зміни, які були встановлені, але не виконані, а потім перезаписані наприклад, наприклад інший git add є через git fsck --unreachable який буде перелічувати всі недоступні об'єкти, які ви можете перевірити до git show SHA-1_ID або git fsck --lost-found що буде> Написати зависання об'єктів в .git/lost-found/commit/ або .git/lost-found/other/, залежно від типу. Дивись також git fsck --help - iolsmit


git rm --cached . -r

буде "un-add" все, що ви додали з поточного каталогу рекурсивно


85
2017-12-09 21:19



Я не шукав, щоб не додати все, тільки один конкретний файл. - paxos1977
Також корисно, якщо у вас немає попередніх команд. За відсутності попереднього зобов'язання git reset HEAD <file> сказав би fatal: Failed to resolve 'HEAD' as a valid ref. - Priya Ranjan Singh
Ні, це додає a видалення всього у вашому поточному каталозі. Дуже відрізняється від просто незмінних змін. - Mark Amery


Біжи

git gui

і видалити всі файли вручну або вибравши всі з них і натиснувши на Не використовуйте фіксацію кнопка


77
2017-10-12 01:12



Так, я це розумію. Я просто хотів неявно припустити, що ви вкажете, що за вашою відповіддю, як "Ви можете використовувати git-gui.... ":) - Alexander Suraphel
Він говорить: "git-gui: команда не знайдена". Я не знаю, чи це працює. - Parinda Rajapaksha


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

Що ти робив раніше:

  • Змінено файл і використано git add ., або git add <file>.

Що ти хочеш:

  • Вилучіть файл з індексу, але залишайте його версією та залишайте за незмінними змінами у робочій копії:

    git reset head <file>
    
  • Скиньте файл на останній стан HEAD, скасовуючи зміни та вилучаючи їх з індексу:

    # Think `svn revert <file>` IIRC.
    git reset HEAD <file>
    git checkout <file>
    
    # If you have a `<branch>` named like `<file>`, use:
    git checkout -- <file>
    

    Це потрібно з того часу git reset --hard HEAD не буде працювати з окремими файлами.

  • Видалити <file> від індексу та версії, збереження файлу без версії з змінами в робочій копії:

    git rm --cached <file>
    
  • Видалити <file> від робочої копії та версії повністю:

    git rm <file>
    

73
2018-03-29 11:14



Я не можу зазнати різниці в "git reset head <file>" і "git rm --cached <file>. Не могли б ви це пояснити? - jeswang
@ jeswang файли або "відомі" в git (зміни в них відслідковуються), або вони не "версії". reset head скасовує ваші поточні зміни, але файл все ще контролюється git. rm --cached виводить файл з версії, тому git більше не перевіряє його для змін (а також знімає в кінцевому підсумку індексацію поточних змін, повідомлених git попереднім add), але змінений файл буде збережений у вашій робочій копії, тобто в папці файлів на жорсткому диску. - sjas
Різниця git reset HEAD <file> є тимчасовим - команда буде застосована лише до наступної передачі, але git rm --cached <file> не буде завантажено доти, доки його знову додадуть з git add <file>. Крім того, git rm --cached <file> означає, якщо ви натиснете цю гілку на пульт, хтось, що потягнув гілку, отримає файл, дійсно видалений з їхньої папки. - DrewT


Питання не чітко поставлено. Причина в тому, що git add має два значення:

  1. додаючи a новий файл до місця розташування, а потім скасувати з git rm --cached file.
  2. додаючи a модифікований файл до місця постановки, а потім скасувати з git reset HEAD file.

якщо ви сумніваєтеся, скористайтеся

git reset HEAD file

Оскільки це робить очікувану річ у обох випадках.

УВАГА: Якщо ти зробиш git rm --cached file на файл, який був модифікований (файл, який існував раніше в репозиторії), то файл буде видалено git commit! Вона все одно буде існувати у вашій файловій системі, але якщо хтось ще тягне вашу фіксацію, файл буде видалено з їхнього дерева.

git status скаже вам, чи був файл a новий файл або модифікований:

On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   my_new_file.txt
    modified:   my_modified_file.txt

62
2018-01-16 19:54



+1 Надзвичайна кількість високооплачуваних відповідей та коментарів на цій сторінці є просто невірним з приводу поведінки git rm --cached somefile. Я сподіваюсь, що ця відповідь повертає сторінку до видатної позиції, де вона може захистити новачків від введення в оману за всіма фальшивими претензіями. - Mark Amery


Скасувати файл, який вже додано, досить простий у використанні гіт, для скидання myfile.txt який вже додав, використовуйте:

git reset HEAD myfile.txt

Поясніть:

Після того як ви встановили небажані файли, ви можете скасувати їх git reset, Head головка вашого файлу в локальному, а останній параметр - ім'я вашого файлу.

Я створюю кроки, наведені на малюнку нижче, для більш докладної інформації про вас, включаючи всі кроки, які можуть статися в таких випадках:

git reset HEAD


60
2018-06-28 10:43





Якщо ви берете участь у вашій першій програмі, і ви не можете використовувати скидання git, просто заявляйте про "банкрутство Git" та видаліть папку .git і розпочніть знову.


55
2017-11-19 16:39



Одним з підказок є копіювання файлу .git / config, якщо ви додали віддалене джерело, перш ніж видаляти папку. - Tiago
@ ChrisJohnsen коментар на місці. Іноді ви хочете зробити всі файли, крім одного: git add -A && git rm --cached EXCLUDEFILE && git commit -m 'awesome commit'  (Це також працює, коли немає попередніх команд, повторно Failed to resolve 'HEAD' проблема) - Barry