status git menunjukkan modifikasi, checkout git - <file> tidak menghapusnya


222

Saya ingin menghapus semua perubahan pada copy pekerjaan saya.
Menjalankan git statusmenunjukkan file yang dimodifikasi.
Sepertinya tidak ada yang saya lakukan untuk menghapus modifikasi ini.
Misalnya:

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git checkout -- Rhino.Etl.Core/Enumerables/CachingEnumerable.cs

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git checkout `git ls-files -m`

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git reset --hard HEAD
HEAD is now at 6c857e7 boo libraries updated to 2.0.9.2 and rhino.dsl.dll updated.

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

6
Tidak yakin mengapa git reset --hardtidak bekerja di sini. Catatan: seharusnya git checkout -- `git ls-files -m`membatalkan file ( --)
VonC

2
Jika Anda menghapus file dan menggunakannya checkout -- <file>harus berfungsi. Deteksi perubahan agak pilih-pilih dalam beberapa situasi (antara lain jika ketidakcocokan CRLF hadir)
eckes

Kemungkinan duplikat dari Tidak bisa membuang perubahan di Git
BuZZ-dEE

1
@ BuZZ-dEE - ini adalah duplikat, dan lebih tua dan karenanya akan diutamakan. Tetapi sementara pertanyaan yang Anda tautkan pada dasarnya sama, jawaban yang saya terima di bawah ini jauh lebih informatif daripada semua jawaban di sana, dan menyelesaikan masalah saya.
rbellamy

bukan solusi, tetapi pisau swiss untuk kasus membosankan: git update-index --assume-unchagedmemaksa keadaan file yang tidak beraturan (bahkan untuk file yang diubah!)
pdem

Jawaban:


126

Ada beberapa masalah yang dapat menyebabkan perilaku ini:

Normalisasi akhiran garis

Saya juga punya masalah seperti ini. Itu turun ke git secara otomatis mengkonversi crlf ke lf. Ini biasanya disebabkan oleh akhir baris campuran dalam satu file. File akan dinormalisasi dalam indeks, tetapi ketika git kemudian mendenormalkannya lagi untuk berbeda dengan file di pohon yang bekerja, hasilnya berbeda.

Tetapi jika Anda ingin memperbaikinya, Anda harus menonaktifkan core.autocrlf , ubah semua ujung baris menjadi Jika, dan kemudian aktifkan lagi. Atau Anda dapat menonaktifkannya sama sekali dengan melakukan:

git config --global core.autocrlf false

Alih-alih core.autocrlf , Anda juga dapat mempertimbangkan untuk menggunakan .gitattributefile. Dengan cara ini, Anda dapat memastikan semua orang menggunakan repo menggunakan aturan normalisasi yang sama, mencegah akhir baris campuran masuk ke dalam repositori.

Juga pertimbangkan untuk mengatur core.safecrlf untuk memperingatkan jika Anda ingin git memperingatkan Anda ketika normalisasi yang tidak dapat dibalik akan dilakukan.

Manual git mengatakan ini:

Konversi CRLF memiliki sedikit peluang untuk merusak data. autocrlf = true akan mengonversi CRLF ke LF selama komit dan LF ke CRLF selama checkout. File yang berisi campuran LF dan CRLF sebelum komit tidak dapat dibuat kembali oleh git. Untuk file teks, ini adalah hal yang benar untuk dilakukan: itu memperbaiki akhir baris sehingga kita hanya memiliki ujung baris LF dalam repositori. Tetapi untuk file biner yang secara tidak sengaja diklasifikasikan sebagai teks konversi dapat merusak data.

Sistem file case-insensitive

Pada sistem file case-insensitive, ketika nama file yang sama dengan casing berbeda ada di repositori, git mencoba untuk checkout keduanya, tetapi hanya satu yang berakhir pada sistem file. Ketika git mencoba membandingkan yang kedua, ia akan membandingkannya dengan file yang salah.

Solusinya adalah beralih ke sistem file yang tidak sensitif terhadap kasus, tetapi ini dalam kebanyakan kasus tidak layak atau mengganti nama dan melakukan salah satu file pada sistem file lain.


8
Oke ... sehingga berhasil ... sekarang status git tidak menunjukkan perubahan. Saya sudah membaca tentang pengaturan autocrlf, dan sepertinya saya tidak bisa memperbaikinya.
rbellamy

1
Tangkapan yang bagus! +1. Namun argumen lain bagi saya untuk mengatur itu menjadi false ( stackoverflow.com/questions/1249932/… ).
VonC

Apa artinya ini: "File yang berisi campuran LF dan CRLF sebelum komit tidak dapat dibuat kembali oleh git." Apakah ini karena git akan selalu menormalkan akhir baris, berdasarkan pada pengaturan core.autocrlf?
rbellamy

1
Solusi yang lebih waras untuk masalah sensitivitas kasing adalah tidak memiliki banyak folder di repo Anda yang namanya hanya berbeda-beda .
Ohad Schneider

3
Untuk menemukan nama file yang berbeda hanya dengan huruf, Anda dapat menjalankan git ls-tree -r --name-only HEAD | tr A-Z a-z | sort | uniq -d. Untuk membuat daftar nama huruf besar dan kecil dari file tersebut jalankangit ls-tree -r --name-only HEAD | fgrep -i -f <(git ls-tree -r --name-only HEAD | tr A-Z a-z | sort | uniq -d) | sort -i
Diomidis Spinellis

220

Saya mengalami masalah ini pada Windows tetapi tidak siap untuk melihat konsekuensi dari penggunaannya. config --global core.autocrlf falseSaya juga tidak siap untuk meninggalkan cabang dan barang pribadi lainnya di simpanan saya dan mulai dengan klon baru. Saya hanya perlu menyelesaikan sesuatu. Sekarang.

Ini berhasil bagi saya, dengan gagasan bahwa Anda membiarkan git menulis ulang direktori kerja Anda sepenuhnya:

git rm --cached -r .
git reset --hard

(Perhatikan bahwa menjalankan saja git reset --hardtidak cukup baik dan juga tidak ada rmpada file sebelum resetseperti yang disarankan dalam komentar untuk pertanyaan asli)


8
Kesuksesan lain di sini setelah perubahan core.autocrlftidak berpengaruh.
Daniel Buckmaster

8
Sedang mengalami masalah ini di Windows bahkan dengan core.autocrlf false. Jawaban ini berhasil ketika tidak ada yang lain.
kenchilada

9
Saya sudah mencoba banyak saran dari ini dan pertanyaan lainnya. Ini adalah satu-satunya perbaikan yang berhasil untuk saya. Saya tidak punya file atribut dan saya sudah mulai dengan core.autocrlf di false.
BrotherOdin

4
Ini tidak berhasil untuk saya. Jadi, saya melakukannya dengan cara yang lebih buruk dengan membuat cabang baru hanya untuk melakukan perubahan ini karena mereka tidak berguna bagi saya. [java] git checkout -b a-branch-to-commit-bad-crlf-files [/ java] [java] git commit -am "melakukan file crlf buruk" [/ java]
Mohd Farid

3
Terkadang masalah seperti ini membuat saya sangat merindukan SVN.
Mike Godin

104

Solusi lain yang dapat bekerja untuk orang, karena tidak ada opsi teks yang berfungsi untuk saya:

  1. Mengganti isi .gitattributesdengan satu baris: * binary. Ini memberitahu git untuk memperlakukan setiap file sebagai file biner yang tidak dapat digunakannya.
  2. Periksa bahwa pesan untuk file yang menyinggung sudah tidak ada; jika tidak, Anda dapat git checkout -- <files>mengembalikannya ke versi repositori
  3. git checkout -- .gitattributesuntuk mengembalikan .gitattributesfile ke kondisi awal
  4. Pastikan file masih belum ditandai sebagai diubah.

1
Saya macet karena tidak dapat mengembalikan, menarik, atau menyimpan file selama beberapa jam terakhir. INI memperbaiki untuk saya! Terima kasih! (Git 1.8.3.1)
NuSkooler

3
Saya mencoba banyak hal sebelum akhirnya menemukan kesuksesan dengan ini. Terima kasih!
ghenghy

1
Bagaimana cara kerjanya? Saya akan berpikir .gitattributeskembali ke aslinya akan memperkenalkan kembali masalah yang sama, tetapi sayangnya masalah saya sekarang terpecahkan. Tidak ada saran lain yang berhasil dalam kasus saya.
jdk1.0

1
@ jdk1.0 pemahaman saya / duga saya adalah bahwa dua metode perbandingan yang berbeda terlibat. Kesalahan terjadi ketika Anda memiliki garis yang berbeda yang berakhir di suatu tempat, dan git terkadang mengabaikannya. Ketika Anda bertanya git status, itu menemukan bahwa mereka adalah file yang berbeda. Ketika Anda bertanya git checkout, ia menemukan bahwa mereka memiliki konten yang sama. Solusi ini sementara memerintahkan git untuk mengabaikan kepintaran akhir baris yang mungkin, dan memastikan bahwa salinan lokal Anda adalah byte-untuk-byte yang identik dengan itu HEAD. Setelah itu diselesaikan, mengizinkan kepintaran untuk melanjutkan tidak apa-apa, karena itu tidak akan menambah kesalahan baru.
zebediah49

3
Telah menghabiskan beberapa jam berurusan dengan ini dan solusi ini akhirnya berhasil untuk saya!
Maryam

71

Untuk orang-orang di masa depan yang mengalami masalah ini: Memiliki perubahan filemode juga dapat memiliki gejala yang sama. git config core.filemode falseakan memperbaikinya.


3
Setelah melakukan ini, Anda mungkin perlu melakukangit checkout .
Marty Neal

2
Bekerja untuk saya tanpa harus checkout lagi
phillee

3
Untuk referensi di masa mendatang: untuk mengetahui apakah ini perbaikan yang Anda butuhkan (dan bukan perbaikan lain di jawaban lain), gunakan git diffdan itu akan menampilkan file dengan perubahan mode seperti ini old mode 100755 / new mode 100644.
hal

Ini memperbaikinya bagi saya setelah benar-benar tidak ada lagi yang mau. Saya benar-benar tidak berpikir orang harus membuat cheat sheet git dan "panduan sederhana" di internet. Git benar-benar bukan sesuatu untuk diambil dan digunakan, saya pikir itu adalah sesuatu yang harus Anda dedikasikan dan latih secara formal dan latih sebelum Anda menggunakannya.

Terima kasih, Anda menyelamatkan saya banyak air mata!
Lukasz

33

Ini telah membuatku gila, terutama karena aku tidak bisa memperbaikinya tanpa ada solusi yang ditemukan online. Inilah cara saya menyelesaikannya. Tidak dapat mengambil kredit di sini karena ini adalah karya seorang rekan :)

Sumber masalah: Instalasi awal git saya tanpa konversi baris otomatis di windows. Ini menyebabkan komit awal saya ke GLFW menjadi tanpa garis akhir yang tepat.

Catatan: Ini hanya solusi lokal. Orang berikutnya yang mengkloning repo masih akan terjebak dengan masalah ini. Solusi permanen dapat ditemukan di sini: https://help.github.com/articles/dealing-with-line-endings/#re-normalizing-a-repository .

Setup: Xubuntu 12.04 Git repo dengan proyek glfw

Masalah: Tidak dapat mengatur ulang file glfw. Mereka selalu ditampilkan sebagai dimodifikasi, terlepas dari apa yang saya coba.

Terpecahkan:

edit .gitattributes

Comment out the line:    # text=auto

Save the file

restore .gitattributes:   git checkout .gitattributes

Mungkin bermanfaat untuk menyebutkan isi dari baris komentar.
rbellamy

Sayangnya, sebagian besar proyek tidak memiliki file .gitattribute opsional ini
mchiasson

Terima kasih. Saya hanya tidak mengerti mengapa ini perlu
diogovk

Mengapa? Pada dasarnya, ini adalah perbaikan sementara untuk akhir baris. Gunakan solusi permanen dengan mengikuti tautan di Catatan.
Richard Lalancette

11

Saya punya file .bat dengan masalah yang sama (tidak bisa menghapusnya dalam file yang tidak terlacak). git checkout - tidak berfungsi, juga tidak ada saran di halaman ini. Satu-satunya hal yang berhasil bagi saya adalah melakukan:

git stash save --keep-index

Dan kemudian untuk menghapus simpanan:

git stash drop

Ini berhasil untuk saya. Perhatikan bahwa --keep-indexini penting.
user991710

Mengapa --keep-index penting?
Choylton B. Higginbottom

8

Mendapat masalah yang sama dua kali! Kedua kali ketika menyimpan beberapa perubahan yang saya buat dan kemudian mencoba untuk mengembalikannya. Tidak bisa menampilkan perubahan karena saya punya banyak file yang diubah - tetapi TIDAK! Persis sama.

Saya sekarang berpikir saya sudah mencoba semua solusi di atas tanpa hasil. Setelah mencoba

git rm --cached -r .
git reset --hard

Sekarang saya mendapatkan hampir semua file di repositori saya dimodifikasi.

Ketika membuat file berbeda, dikatakan saya telah menghapus semua baris dan kemudian menambahkannya lagi.

Agak mengganggu. Saya sekarang akan menghindari menyembunyikan di masa depan ..

Satu-satunya solusi adalah mengkloning repositori baru dan memulai dari awal. (Berhasil terakhir kali)


6

Coba lakukan a

git checkout -f

Itu harus menghapus semua perubahan dalam repo lokal yang berfungsi saat ini


Bagus! Ini berhasil untuk saya. Meskipun untuk satu kasus keras kepala saya harus terlebih dahulu git checkout -f <another recent branch>kemudian kembali ke cabang saya dengangit checkout -f <branch I'm working on>
Reversed Engineer

4

Saya hanya dapat memperbaiki ini dengan menghapus sementara file .gitattributes repo saya (yang didefinisikan * text=autodan *.c text).

Saya berlari git statussetelah menghapus dan modifikasi hilang. Mereka tidak kembali bahkan setelah atribut .Git ditempatkan kembali di tempatnya.


Ini berfungsi bahkan dengan gitattribut yang lebih rumit misalnya filter
Samizdis

2

Memiliki akhiran garis yang konsisten adalah hal yang baik. Misalnya itu tidak akan memicu penggabungan yang tidak perlu, meskipun sepele. Saya telah melihat Visual Studio membuat file dengan akhiran garis campuran.

Juga beberapa program seperti bash (di linux) mengharuskan file .sh dihentikan LF.

Untuk memastikan ini terjadi, Anda dapat menggunakan gitattributes. Ia bekerja pada level repositori, apa pun nilai autcrlf.

Misalnya, Anda dapat memiliki .gitattributes seperti ini: * text = auto

Anda juga bisa lebih spesifik per jenis file / ekstensi jika itu penting dalam kasus Anda.

Kemudian autocrlf dapat mengonversi akhiran baris untuk program Windows secara lokal.

Pada campuran C # / C ++ / Java / Ruby / R, proyek Windows / Linux ini bekerja dengan baik. Sejauh ini tidak ada masalah.


2

Saya juga memiliki gejala yang sama tetapi disebabkan oleh hal yang berbeda.

Saya tidak dapat untuk:

git checkout app.js //did nothing
git rm app.js //did nothing
rm -rf app.js //did nothing

bahkan di git rm --cached app.jsatasnya menandatangani sebagai dihapus dan dalam file yang tidak terlacak saya bisa melihat app.js. Tetapi ketika saya mencoba rm -rf app.jsdan mengupas git statuslagi itu masih menunjukkan saya file dalam 'tidak terlacak'.

Setelah beberapa kali mencoba dengan kolega kami menemukan, bahwa itu disebabkan oleh Grunt!

Ketika Grunttelah dinyalakan, dan karena app.js telah dihasilkan dari beberapa file js lainnya, kami mengetahui bahwa setelah setiap operasi dengan file js (juga app.js) ini, kembali membuat ulang app.js.


2

Masalah ini juga dapat terjadi ketika kontributor repo bekerja di mesin Linux, atau jendela dengan Cygwin dan izin file diubah. Git hanya tahu 755 dan 644.

Contoh masalah ini dan cara memeriksanya:

git diff styleguide/filename

diff --git a/filename b/filename
old mode 100644
new mode 100755

Untuk menghindari ini, Anda harus memastikan bahwa Anda mengatur git dengan benar

git config --global core.filemode false

2

Ada banyak solusi di sini dan saya mungkin harus mencoba beberapa dari ini sebelum saya membuat sendiri. Lagi pula, ini satu lagi ...

Masalah kami adalah bahwa kami tidak memiliki penegakan untuk endline dan repositori memiliki campuran DOS / Unix. Lebih buruk lagi adalah bahwa itu sebenarnya repo sumber terbuka di posisi ini, dan yang kami telah bercabang dua. Keputusan itu dibuat oleh orang-orang dengan kepemilikan utama repositori OS untuk mengubah semua endline menjadi Unix dan komit dibuat yang mencakup a .gitattributesuntuk menegakkan akhir baris.

Sayangnya ini sepertinya menyebabkan masalah seperti yang dijelaskan di sini di mana setelah penggabungan kode dari sebelum DOS-2-Unix dilakukan, file akan selamanya ditandai sebagai diubah dan tidak dapat dikembalikan.

Selama penelitian saya untuk ini saya menemukan - https://help.github.com/articles/dealing-with-line-endings/ - Jika saya menghadapi masalah ini lagi, saya akan mulai dengan mencoba ini.


Inilah yang saya lakukan:

  1. Saya awalnya melakukan penggabungan sebelum menyadari bahwa saya memiliki masalah ini dan harus membatalkannya - git reset --hard HEAD( Saya mengalami konflik penggabungan. Bagaimana saya bisa membatalkan penggabungan? )

  2. Saya membuka file yang dimaksud di VIM dan berubah menjadi Unix ( :set ff=unix). Alat seperti ini dos2unixbisa digunakan sebagai ganti tentu saja

  3. berkomitmen

  4. menggabungkan masterin (master memiliki perubahan DOS-2-Unix)

    git checkout old-code-branch; git merge master

  5. Konflik yang diselesaikan dan file-file itu DOS lagi jadi harus :set ff=unixketika di VIM. (Catatan saya telah menginstal https://github.com/itchyny/lightline.vim yang memungkinkan saya melihat format file pada status VIM)

  6. berkomitmen. Semua disortir!

2

Masalah yang saya temui adalah windows tidak peduli dengan kapitalisasi nama file, tetapi git tidak. Jadi git menyimpan versi file yang lebih kecil dan besar tetapi hanya bisa checkout satu.


2

Saya melakukan semua perubahan dan kemudian melakukan dan membatalkan komit. Ini berhasil untuk saya

git add.

git commit -m "Komit acak"

atur ulang git --hard HEAD ~ 1


2

Biasanya, di GIT untuk menghapus semua modifikasi Anda & file baru, 2 perintah berikut harus bekerja dengan sangat baik ( HATI - HATI , ini akan menghapus semua file + folder baru Anda yang mungkin Anda buat & akan mengembalikan semua file Anda yang dimodifikasi ke keadaan saat ini Anda melakukan ):

$ git clean --force -d
$ git checkout -- .

Mungkin opsi yang lebih baik kadang-kadang hanya melakukan "git stash push" dengan pesan opsional, seperti:

$ git stash push -m "not sure if i will need this later"

Ini juga akan menghapus semua file baru dan modifikasi Anda, tetapi Anda akan menyimpan semuanya jika Anda ingin mengembalikannya. Stash in GIT membawa dari cabang ke cabang, sehingga Anda dapat mengembalikannya ke cabang lain, jika diinginkan.

Sebagai catatan, jika Anda telah melakukan beberapa file yang baru ditambahkan dan ingin menyingkirkannya, ini harus dilakukan:

$ git reset --hard

Jika semua hal di atas tidak bekerja untuk Anda , baca di bawah ini apa yang bekerja untuk saya beberapa saat yang lalu:

Saya mengalami masalah ini beberapa kali sebelumnya. Saat ini saya sedang mengembangkan mesin Windows 10 yang disediakan oleh perusahaan saya. Hari ini, perilaku git khusus ini disebabkan oleh saya membuat cabang baru dari cabang "berkembang" saya. Untuk beberapa alasan, setelah saya beralih kembali ke "mengembangkan" cabang, beberapa file yang tampaknya acak bertahan dan muncul sebagai "dimodifikasi" dalam "status git".

Juga, pada saat itu saya tidak bisa checkout cabang lain, jadi saya terjebak di cabang "berkembang" saya.

Inilah yang saya lakukan:

$ git log

Saya perhatikan bahwa cabang baru yang saya buat dari "berkembang" sebelumnya hari ini menunjukkan dalam pesan "komit" pertama, yang direferensikan pada akhir "KEPALA -> mengembangkan, asal / mengembangkan, asal / KEPALA, cabang-i-dibuat -lebih dulu-hari ini ".

Karena saya tidak benar-benar membutuhkannya, saya menghapusnya:

$ git branch -d The-branch-i-created-earlier-today

File yang diubah masih muncul, jadi saya lakukan:

$ git stash

Ini menyelesaikan masalah saya:

$ git status
On branch develop
Your branch is up to date with 'origin/develop'.

nothing to commit, working tree clean

Tentu saja $ git stash listakan menunjukkan perubahan simpanan, dan karena saya memiliki sedikit dan tidak memerlukan simpanan saya, saya lakukan $ git stash clearuntuk HAPUS SEMUA GAGASAN.

CATATAN : Saya belum mencoba melakukan apa yang disarankan seseorang di sini sebelum saya:

$ git rm --cached -r .
$ git reset --hard

Ini mungkin berhasil juga, saya pasti akan mencobanya lain kali saya mengalami masalah ini.


1

Jika Anda mengkloning repositori dan langsung melihat perubahan yang tertunda, maka repositori dalam kondisi tidak konsisten. Tolong JANGAN berkomentar keluar * text=autodari .gitattributesfile. Itu diletakkan di sana secara khusus karena pemilik repositori ingin semua file disimpan secara konsisten dengan ujung garis LF.

Sebagaimana dinyatakan oleh HankCa, mengikuti petunjuk di https://help.github.com/articles/dealing-with-line-endings/ adalah cara untuk memperbaiki masalah tersebut. Tombol mudah:

git clone git@host:repo-name
git checkout -b normalize-line-endings
git add .
git commit -m "Normalize line endings"
git push
git push -u origin normalize-line-endings

Kemudian gabungkan (atau tarik permintaan) cabang ke pemilik repo.


1

Tidak ada hal lain di halaman ini yang berfungsi. Ini akhirnya berhasil untuk saya. Menampilkan tidak ada file tidak terlacak, atau berkomitmen.

git add -A
git reset --hard

1

Bagi saya masalahnya adalah Visual Studio dibuka ketika melakukan perintah

git checkout <file>

Setelah menutup Visual Studio, perintah itu berhasil dan saya akhirnya bisa menerapkan pekerjaan saya dari stack. Jadi periksa semua aplikasi yang dapat membuat perubahan pada kode Anda, misalnya SourceTree, SmartGit, NotePad, NotePad ++ dan editor lainnya.


0

Kami menghadapi situasi serupa di perusahaan kami. Tidak ada metode yang diusulkan tidak membantu kami. Sebagai hasil dari penelitian, masalah terungkap. Masalahnya adalah bahwa di Git ada dua file, yang namanya hanya berbeda dalam register simbol. Sistem Unix melihat mereka sebagai dua file yang berbeda, tetapi Windows menjadi gila. Untuk mengatasi masalah tersebut, kami menghapus salah satu file di server. Setelah itu, di repositori lokal di Windows membantu beberapa perintah berikutnya (dalam urutan yang berbeda):

git reset --hard
git pull origin
git merge

0

Saya menyelesaikannya dengan mengedit .git / config, menambahkan:

[branch "name_branch"]
    remote = origin
    merge = refs/heads/name_branch

Kemudian saya pergi ke .git / refs / heads / name_branch dan menempatkan id dari commit terakhirenter code here


0

Saya memecahkannya dengan cara ini:

  1. Salin isi kode yang benar yang Anda inginkan
  2. Hapus file yang menyebabkan masalah (salah satu yang Anda tidak dapat mengembalikan) dari disk Anda. sekarang Anda harus menemukan kedua versi file yang sama ditandai sebagai sedang dihapus.
  3. Melakukan penghapusan file.
  4. Buat file lagi dengan nama yang sama dan tempelkan kode yang benar yang telah Anda salin pada langkah 1
  5. komit pembuatan file baru.

Itu yang berhasil untuk saya.


0

Salah satu solusi yang diusulkan di sini tidak berhasil, saya menemukan file itu sebenarnya adalah tautan ke beberapa karakter khusus:

% ls -l StoreLogo.png
lrwxrwxrwx 1 janus janus 8 Feb 21 10:37 StoreLogo.png -> ''$'\211''PNG'$'\r\n\032\n'

% git status    
Changes not staged for commit:
    modified:   StoreLogo.png

% git rm --cached -r StoreLogo.png
rm 'src/GWallet.Frontend.XF.UWP/Assets/StoreLogo.png'

% git reset StoreLogo.png         
Unstaged changes after reset:
M   src/GWallet.Frontend.XF.UWP/Assets/StoreLogo.png

% git status                      
Changes not staged for commit:
    modified:   StoreLogo.png
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.