Як скасувати "git add" перед фіксацією?

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

git add myfile.txt

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

Ви можете скасувати, git addперш ніж здійснити коммісію

git reset <file>

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

Можна використовувати

git reset

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

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

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

Ти хочеш:

git rm --cached <added_file_to_undo>

Обґрунтування:

Коли я був у цьому новому, то спершу спробував

git reset .

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

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

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

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

4. git status

   ... багато лайно прокручує ...

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

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

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

6. git reset .

   => fatal: Не вдалося вирішити 'HEAD' як дійсний номер.

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

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

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

І рішення справді полягає у використанні git rm --cached FILE.

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

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

Приступаю до використання

git rm --cached .

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

git rm -r --cached .

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

git add -n .

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

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

git status

Git розповість, що ставиться та ін., Включаючи інструкції щодо знеструмлення:

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

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

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

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

Для уточнення: 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

На додаток до прийнятої відповіді, якщо ваш помилково доданий файл був величезним, ви, ймовірно, помітите, що навіть після вилучення його з індексу із символом ' 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 ця дія все ще називається додати (не просто її оновити ), оскільки дві різні версії (знімки) файлу розглядаються як два різні елементи: отже, ми дійсно додаємо новий елемент у кеш, щоб бути зрештою вчинено пізніше.

Зважаючи на це, питання є дещо неоднозначним:

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

Сценарій ОП, здається, перший (неповернутий файл), ми хочемо, щоб "скасувати" видалив файл (не лише поточний вміст) з відстежуваних елементів. Якщо це так, то нормально бігати 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 irrevocably lost "version 2"
-version 1
+version 3

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

^{* (Редагувати: вищезазначене практично правильно, але все ж можуть бути кілька зловмисних / заплутаних способів відновлення змін, які були інсценовані, але не скоєні та перезаписані - див. Коментарі Йоханнеса Матокича та iolsmit)}

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

git reset HEAD myfile.txt

Пояснення:

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

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

git rm --cached . -r

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

Біжи

git gui

і видаліть усі файли вручну або, вибравши їх усі та натиснувши кнопку " нестабільність" від кнопки фіксації .

У 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>
  

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

1. додавання нового файлу до області постановки, а потім скасувати git rm --cached file.
2. додавши модифікований файл до області постановки, а потім скасувати git reset HEAD file.

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

git reset HEAD file

Тому що це робить очікуване в обох випадках.

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

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

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

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

Відповідно до багатьох інших відповідей, ви можете використовувати git reset

АЛЕ:

Я знайшов цей чудовий маленький пост, який фактично додає команду Git (ну псевдонім) для git unadd: див. Git unadd для деталей або ..

Просто,

git config --global alias.unadd "reset HEAD"

Тепер ти можеш

git unadd foo.txt bar.txt

Використовуйте git add -iдля видалення щойно доданих файлів із майбутньої фіксації. Приклад:

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

$ git add foo
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file:   foo
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
# [...]#

Перейдіть в інтерактивне додаток, щоб скасувати додавання (команди, введені в git, тут - "r" (відновити), "1" (перший запис у списку повернення показує), "return", щоб вийти з режиму повернення, і "q" (кинути):

$ git add -i
           staged     unstaged path
  1:        +1/-0      nothing foo

*** Commands ***
  1: [s]tatus     2: [u]pdate     3: [r]evert     4: [a]dd untracked
  5: [p]atch      6: [d]iff       7: [q]uit       8: [h]elp
What now> r
           staged     unstaged path
  1:        +1/-0      nothing [f]oo
Revert>> 1
           staged     unstaged path
* 1:        +1/-0      nothing [f]oo
Revert>> 
note: foo is untracked now.
reverted one path

*** Commands ***
  1: [s]tatus     2: [u]pdate     3: [r]evert     4: [a]dd untracked
  5: [p]atch      6: [d]iff       7: [q]uit       8: [h]elp
What now> q
Bye.
$

Це воно! Ось ваш доказ, що показує, що "foo" знову в списку без відстеження:

$ git status
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
# [...]
#       foo
nothing added to commit but untracked files present (use "git add" to track)
$

git removeабо git rmможна використовувати для цього за допомогою --cachedпрапора. Спробуйте:

git help rm

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

• Створіть основний каталог для вашого нового проекту.
• Біжи git init.
• Тепер створіть файл .gitignore (навіть якщо він порожній).
• Введіть файл .gitignore.

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

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

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

Можливо, Git розвинувся з моменту, коли ви опублікували своє запитання.

$> git --version
git version 1.6.2.1

Тепер ви можете спробувати:

git reset HEAD .

Це має бути те, що ви шукаєте.

Зауважте, що якщо не вдалося вказати версію, вам доведеться включити роздільник. Приклад з моєї консолі:

git reset <path_to_file>
fatal: ambiguous argument '<path_to_file>': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions

git reset -- <path_to_file>
Unstaged changes after reset:
M    <path_to_file>

(Версія Git 1.7.5.4)

Щоб видалити нові файли з області постановки (і лише у випадку нового файлу), як було запропоновано вище:

git rm --cached FILE

Використовуйте rm --cached лише для нових випадково доданих файлів.

Щоб скинути кожен файл у певній папці (та її підпапках), ви можете скористатися такою командою:

git reset *

Використовуйте *команду для обробки декількох файлів одночасно:

git reset HEAD *.prj
git reset HEAD *.bmp
git reset HEAD *gdb*

тощо.

Просто введіть git resetйого назад, і це так, як ви ніколи не вводили git add .з моменту останнього вчинення. Переконайтеся, що ви здійснили раніше.

Припустимо, я створюю новий файл newFile.txt:

Припустимо, я додаю файл випадково git add newFile.txt:

Тепер я хочу скасувати це додавання перед фіксацією git reset newFile.txt:

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

• git скидання my_file.txt
• git checkout my_file.txt

Для всіх доданих файлів:

• git reset.
• git checkout.

Примітка. Каса змінює код у файлах і переходить до останнього оновленого (скоєного) стану. скидання не змінює коди; він просто скидає заголовок.

Ця команда видалить ваші зміни:

git reset HEAD filename.txt

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

git add -p 

для додавання частин файлів.

Є також інтерактивний режим:

git add -i

Виберіть варіант 3, щоб скасувати додавання файлів. У моєму випадку я часто хочу додати більше одного файлу, і в інтерактивному режимі ви можете використовувати такі цифри, щоб додати файли. Це займе всіх, крім 4: 1, 2, 3 та 5

Щоб вибрати послідовність, просто введіть 1-5, щоб взяти всі від 1 до 5.

Постановка файлів Git

Щоб скасувати git add, скористайтеся:

git reset filename

git reset filename.txt

Видалить файл з ім'ям filename.txt з поточного індексу, область "збирається зробити", не змінюючи нічого іншого.

git add myfile.txt # Це додасть ваш файл до списку, який потрібно виконати

Зовсім протилежне цій команді,

git reset HEAD myfile.txt  # This will undo it.

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

Він скине вашу голову із вказаним файлом. тож, якщо у вашій голові цього немає, це просто скине її.

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

Я створив новий файл і додав його до Git. Потім я зняв її з використанням GUI Sourcetree. Це результат:

Видалення файлів [12.12.2015 10:43] git -c diff.mnemonicprefix = false false -c core.quotepath = false -c poverljiv.helper = sourcetree reset -q - шлях / до / file / filename.java

Sourcetree використовує resetдля нестабільності нових файлів.

git reset filename.txt  

Видалить файл з ім'ям filename.txt з поточного індексу, область "збирається зробити", не змінюючи нічого іншого.