Tambahan untuk jawaban yang diterima, jika file Anda yang keliru ditambahkan sangat besar, Anda mungkin akan melihat bahwa, bahkan setelah menghapusnya dari indeks dengan ' git reset', tampaknya masih menempati ruang dalam .gitdirektori.
Ini tidak perlu dikhawatirkan; file tersebut memang masih dalam repositori, tetapi hanya sebagai "objek longgar". Itu tidak akan disalin ke repositori lain (melalui klon, push), dan ruang akhirnya akan direklamasi - meskipun mungkin tidak segera. Jika Anda cemas, Anda dapat menjalankan:
git gc --prune=now
Pembaruan (yang berikut adalah upaya saya untuk menghapus beberapa kebingungan yang dapat timbul dari jawaban yang paling banyak dipilih):
Jadi, yang merupakan nyata undo dari git add?
git reset HEAD <file> ?
atau
git rm --cached <file>?
Sebenarnya, dan jika saya tidak salah: tidak ada .
git add tidak dapat dibatalkan - dengan aman, secara umum.
Mari kita ingat dulu apa yang git add <file>sebenarnya dilakukannya:
Jika <file>itu sebelumnya tidak dilacak , git add menambahkan ke cache , dengan konten saat ini.
Jika <file>itu sudah dilacak , git add menyimpan konten saat ini (snapshot, versi) ke cache. Di Git, tindakan ini masih disebut add , (bukan sekadar memperbaruinya ), karena dua versi (snapshot) file yang berbeda dianggap sebagai dua item berbeda: karenanya, kami memang menambahkan item baru ke cache, untuk menjadi yang terakhir dilakukan nanti.
Sehubungan dengan ini, pertanyaannya sedikit ambigu:
Saya keliru menambahkan file menggunakan perintah ...
Skenario OP tampaknya menjadi yang pertama (file tidak terlacak), kami ingin "undo" menghapus file (bukan hanya konten saat ini) dari item yang dilacak. Jika ini masalahnya, maka tidak masalah untuk dijalankan git rm --cached <file>.
Dan kita juga bisa lari git reset HEAD <file>. Secara umum ini lebih disukai, karena bekerja di kedua skenario: itu juga membatalkan ketika kami salah menambahkan versi dari item yang sudah dilacak.
Tetapi ada dua peringatan.
Pertama: Ada (seperti yang ditunjukkan dalam jawaban) hanya satu skenario di mana git reset HEADtidak berfungsi, tetapi git rm --cachedtidak: repositori baru (tidak ada komitmen). Tapi, sungguh, ini kasus yang praktis tidak relevan.
Kedua: Sadarilah bahwa git reset HEAD tidak dapat secara ajaib memulihkan konten file yang sebelumnya di-cache, itu hanya menyinkronkannya kembali dari KEPALA. Jika salah kaprah kami git addmenimpa versi tidak berkomitmen yang dipentaskan sebelumnya, kami tidak dapat memulihkannya. Karena itulah, sebenarnya, kami tidak dapat membatalkan [*].
Contoh:
$ 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
Tentu saja, ini tidak terlalu kritis jika kita hanya mengikuti alur kerja malas melakukan 'git add' hanya untuk menambahkan file baru (kasus 1), dan kami memperbarui konten baru melalui komit, git commit -aperintah.
* (Sunting: di atas secara praktis benar, tetapi masih ada beberapa cara yang agak retas / berbelit-belit untuk memulihkan perubahan yang dipentaskan, tetapi tidak dilakukan dan kemudian ditimpa - lihat komentar oleh Johannes Matokic dan iolsmit)
HEADatauheadsekarang dapat menggunakan@di tempatHEADsebaliknya. Lihat jawaban ini (bagian terakhir) untuk mempelajari mengapa Anda bisa melakukan itu.