Sonra git reset --hard, git statusbeni içinde dosyaları verir Changes not staged for commit:bölüm.

Ben de denedim git reset ., git checkout -- .ve git checkout-index -f -aboşuna.

Peki, bu değişmemiş değişikliklerden nasıl kurtulabilirim?

Bu sadece Visual Studio proje dosyalarını vurmuş gibi görünüyor. Tuhaf. Bu macuna bakın: http://pastebin.com/eFZwPn9Z . Bu dosyalar ile özel olan, sahip olduğum .gitattributes içinde:

*.sln        eol=crlf
*.vcproj     eol=crlf
*.vcxproj*   eol=crlf

Ayrıca, autocrlfglobalimde false olarak ayarlanmıştır .gitconfig. Bu bir şekilde alakalı olabilir mi?

Aynı sorunu yaşadım ve .gitattributesdosya ile ilgiliydi . Ancak soruna neden olan dosya türü .gitattributes.

Sorunu basitçe çalıştırarak çözebildim

git rm .gitattributes
git add -A
git reset --hard

ÇÖZÜLDÜ !!!

Aşağıdaki adımları kullanarak bu sorunu çözdüm

1) Her dosyayı Git'in dizininden kaldırın.

git rm --cached -r .

2) Tüm yeni satır sonlarını almak için Git dizinini yeniden yazın.

git reset --hard

Çözüm git sitesinde açıklanan adımların bir parçasıydı https://help.github.com/articles/dealing-with-line-endings/

Git depoda olmayan dosyaları sıfırlamaz. Böylece yapabilirsiniz:

$ git add .
$ git reset --hard

Bu işlem tüm değişiklikleri aşamalıp Git'in bu dosyalardan haberdar olmasını sağlar ve ardından bunları sıfırlar.

Bu işe yaramazsa, değişikliklerinizi saklamayı ve bırakmayı deneyebilirsiniz:

$ git stash
$ git stash drop

Windows için Git'i kullanıyorsanız, bu büyük olasılıkla sorununuzdur

Aynı sorunu yaşadım ve saklamak, sert sıfırlamak, temizlemek ya da hepsi hala değişiklikleri geride bırakıyordu. Sorun ortaya çıkan git tarafından düzgün ayarlanmamış x dosya modu oldu. Bu Windows için git ile "bilinen bir sorundur". Yerel değişiklikler gitk ve git durumunda gerçek dosya farklılıkları olmadan eski mod 100755 yeni mod 100644 olarak gösterilir.

Düzeltme, dosya modunu yoksaymaktır:

git config core.filemode false

Daha fazla bilgi burada

Tamam, sorunu çözdüm.

Aşağıdakileri .gitattributesiçeren dosya gibi görünüyordu :

*.sln        eol=crlf
*.vcproj     eol=crlf
*.vcxproj*   eol=crlf

proje dosyalarının işaretsiz görünmesini sağladı. Neden olduğunu bilmiyorum ve gerçekten git yollarına özel birinin bize güzel bir açıklama yapmasını umuyorum.

Benim düzeltme bu dosyaları kaldırmak için, ve eklemek oldu autocrlf = falsealtında [core]yer .git/config.

Bu, her geliştiricinin sahip olmasını gerektirdiğinden, önceki yapılandırmayla tam olarak aynı şey değildir autocrlf = false. Daha iyi bir düzeltme bulmak istiyorum.

DÜZENLE:

Suçlayıcı çizgileri yorumladım, onları rahatsız ettim ve işe yaradı. Ne ... ben bile ...!

Olası Neden # 1 - Satır Sonu Normalizasyonu

Bunun olabileceği durumlardan biri, söz konusu dosyanın, satır sonları (1) için doğru yapılandırma olmadan havuzda kontrol edilmesi, havuzda yanlış satır sonları veya karışık satır sonları olan bir dosyaya neden olmasıdır. Onaylamak için, git diffyalnızca satır sonlarındaki değişiklikleri gösterdiğini doğrulayın (bunlar varsayılan olarak görünmeyebilir, git diff | cat -vsatır başlarını değişmez ^Mkarakterler olarak görmeye çalışın ).

Daha sonra, birisi muhtemelen satır sonlarını normalleştirmek .gitattributesiçin bir core.autocrlfayar ekledi veya değiştirdi (2). Dayanarak .gitattributesveya global geneli, Git istenen normalleşmesini biten çizgi uygulamak için çalışma kopyasına yerel değişiklikleri uygulamıştır. Ne yazık ki, bazı nedenlerden dolayı git reset --hardbu çizgi normalizasyon değişikliklerini geri almaz.

Çözüm

Yerel satır sonlarının sıfırlandığı geçici çözümler sorunu çözmez. Dosya git tarafından her "görüldüğünde" normalleşmeyi tekrar dener ve aynı soruna neden olur.

En iyi seçenek, git'in repodaki tüm satır sonlarını eşleştirmek için normalleştirerek .gitattributesve bu değişiklikleri yaparak normalleştirmeyi uygulamasına izin vermektir - bkz. Satır uçlarını git filtre dalı ile düzeltmeye çalışmak, ancak şansı yok .

Eğer gerçekten değişiklikleri el ile geri döndürmek istiyorsanız, o zaman en kolay çözüm değiştirilmiş dosyaları silmek ve daha sonra bu çözümü tutarlı bir şekilde çalışmıyor gibi göründüğüne dikkat etmeliyim. saat ( UYARI: Değiştirilen dosyalarınızda satır sonları dışında değişiklikler varsa bunu ÇALIŞTIRMAYIN !!):

    git status --porcelain | grep "^ M" | cut -c4- | xargs rm
    git checkout -- .

Depodaki satır sonlarını bir noktada normalleştirmezseniz, bu sorunla karşılaşmaya devam edeceğinizi unutmayın.

Olası Neden # 2 - Büyük / Küçük Harfe Duyarsızlık

İkinci olası neden, Windows veya Mac OS / X'te büyük / küçük harfe duyarsızlıktır. Örneğin, depoda aşağıdakine benzer bir yol olduğunu varsayalım:

/foo/bar

Şimdi Linux'taki birisi dosyaları /foo/Bar(muhtemelen bir oluşturma aracı veya bu dizini oluşturan bir şey nedeniyle) taahhüt eder ve iter. Linux'ta, bu aslında iki ayrı dizin:

/foo/bar/fileA
/foo/Bar/fileA

Modifiye neden olabilir Windows ya da Mac üzerinde bu repo denetleniyor fileAdışarı, Windows çeklerde çünkü her reset üzerine, sıfırlama olamayacağı, Git /foo/bar/fileA, Windows duyarsız olduğu ve daha sonra çünkü içeriğini üzerine yazar fileAile /foo/Bar/fileA"modifiye" olma onlara sonuçlanan.

Başka bir vaka, büyük / küçük harfe duyarlı olmayan bir dosya sisteminde teslim alındığında çakışmaya neden olacak repoda bulunan tek bir dosya olabilir. Örneğin:

/foo/bar/fileA
/foo/bar/filea

Bu tür sorunlara neden olabilecek başka benzer durumlar da olabilir.

büyük / küçük harf duyarlı olmayan dosya sistemleri bu durumu gerçekten algılamalı ve yararlı bir uyarı mesajı göstermelidir, ancak şu anda değişmemektedir (bu gelecekte değişebilir - git.git posta listesinde bu tartışmaya ve ilgili önerilen yamalara bakın ).

Çözüm

Çözüm, git dizinindeki dosyaların ve Windows dosya sistemindeki durumun hizalanmasıdır. Bu, işlerin gerçek durumunu gösterecek Linux'ta VEYA çok faydalı açık kaynak programı Git-Unite ile Windows'ta yapılabilir . Git-Unite, git dizinine gerekli vaka değişikliklerini uygular ve bu da daha sonra repoya yüklenebilir.

(1) Bu hiçbiri olmadan Windows'u kullanan bir kişi tarafından büyük olasılıkla oldu .gitattributes, söz konusu dosya için tanım ve varsayılan genel ayarı kullanan core.autocrlfhangi false(bkz (2)).

(2) http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/

Diğer yanıtlar çalışmıyorsa, dosyaları eklemeyi ve ardından sıfırlamayı deneyin

$ git add -A
$ git reset --hard

Benim durumumda, git'in izlediği bir sürü boş dosya olduğunda bu yardımcı oldu.

Bunun bir başka nedeni büyük / küçük harfe duyarlı olmayan dosya sistemleri olabilir . Reponuzda aynı düzeyde adları yalnızca büyük / küçük harfe göre farklılık gösteren birden çok klasörünüz varsa, buna çarpmış olursunuz. Emin olmak için web arayüzünü (örneğin GitHub veya VSTS) kullanarak kaynak veri havuzuna göz atın.

Daha fazla bilgi için: https://stackoverflow.com/a/2016426/67824

stashDeğişikliklerinizi kaldırabilir , sonra zulayı bırakabilirsiniz:

git stash
git stash drop

Bu yöntemlerin hiçbiri benim için işe yaramadı, tek çözüm tüm repoyu nuke etmek ve yeniden klonlamaktı. Bu, saklama, sıfırlama, ekleme ve sıfırlama, clrf ayarları, büyük / küçük harf duyarlılığı vb. İçerir.

Temizleme komutunu çalıştırın :

# Remove all untracked files and directories. (`-f` is `force`, `-d` is `remove directories`)

git clean -fd

Kontrol edin .gitattributes.

Benim durumumda var *.js text eol=lfve git seçeneği core.autocrlfoldu true.

Git dosyalarımın satır sonlarını otomatik olarak dönüştürdüğünde ve düzeltmemi engellediğinde ve hatta git reset --hard HEADhiçbir şey yapmadığında beni duruma getiriyor .

Ben yorumlama ile bunu düzeltmek *.js text eol=lfbenim, .gitattributesve ondan sonra onu uncommented.

Görünüşe göre sadece sihir git.

Ben de benzer bir sorunu vurdu .gitattributes, ama benim durumum için GitHub LFS dahil. Bu tam olarak OP'nin senaryosu olmasa da, .gitattributesdosyanın ne yaptığını ve neden "hayali" farklılıklar biçiminde değişmemiş değişikliklere yol açabileceğini göstermek için bir fırsat sağladığını düşünüyorum .

Benim durumumda, zamanın başından beri olduğu gibi havuzumda bir dosya zaten vardı. Kısa bir süre git-lfs trackönce, biraz fazla geniş olan ve bu eski dosyayı eşleştiren bir desen kullanarak yeni bir kural ekledim . Bu dosyayı değiştirmek istemediğimi biliyorum; Dosyayı değiştirmediğimi biliyorum, ama şimdi benim değişmemiş değişikliklerimdeydi ve bu dosyadaki herhangi bir ödeme veya sabit sıfırlama düzeltmeyecekti. Neden?

GitHub LFS uzantısı öncelikle dosya gitüzerinden erişim sağlayan kancalardan yararlanarak çalışır .gitattributes. Genellikle, girdiler .gitattributeseşleşen dosyaların nasıl işleneceğini belirtir. OP durumunda, satır sonlarını normalleştirmekle ilgiliydi; benimkinde, LFS'nin dosya depolamasını işlemesine izin verip vermemeydi. Her iki durumda da, gita hesaplanırken görülen gerçek dosya, dosyayı incelerken gördüğünüz git diffdosyayla eşleşmez. Bu nedenle, bir dosyanın dosyayla .gitattributeseşleşen desen aracılığıyla nasıl işlendiğini değiştirirseniz, dosyada gerçekten bir değişiklik olmasa bile durum raporunda değişmemiş değişiklikler olarak görünür.

Bütün bunlar, soruya "cevabım", .gitattributesdosyadaki değişiklik yapmak istediğiniz bir şeyse, sadece değişiklikleri eklemeniz ve devam etmeniz gerektiğidir. Değilse, .gitattributesne yapmak istediğinizi daha iyi temsil edecek şekilde değiştirin.

Referanslar

1. GitHub LFS Spesifikasyonu - Nesnelerdeki dosyanızı basit bir metin dosyasıyla bir karma ile değiştirmek için cleanve smudgeişlev çağrılarına nasıl bağlandıklarının mükemmel açıklaması git.

2. gitattributes Belgeler - Belgelerinizin işlenme biçimini özelleştirmek için neyin mevcut olduğuna ilişkin tüm ayrıntılar git.

Ben de aynı problemi yaşadım. Yaptım git reset --hard HEADama yine de her yaptığımda git statusbazı dosyaları değiştirilmiş olarak görüyordum.

Benim çözümüm nispeten basitti. Ben sadece IDE (burada Xcode idi) kapattım ve komut satırımı kapatın (burada benim Mac OS terminal oldu) ve tekrar denedim ve çalıştı.

Yine de sorunun nedenini bulamadım.

Git için rasgele yanlış satır sonlarını kasada yazdığı Windows için git ile ilgili bir sorun olduğuna inanıyorum ve tek çözüm, bazı diğer şubeleri kontrol etmek ve değişiklikleri görmezden gelmeye zorlamaktır. Daha sonra üzerinde çalışmak istediğiniz şubeyi kontrol edin.

git checkout master -f
git checkout <your branch>

Bunun kasıtlı olarak yapmış olabileceğiniz değişiklikleri sileceğini unutmayın, bu nedenle bunu yalnızca ödeme işleminden hemen sonra bu sorunla karşılaşırsanız yapın.

Edit: Aslında ilk kez şanslı olabilir. Dalları değiştirdikten sonra biraz ısırdım. Git şubeleri değiştikten sonra git dosyalarının değiştirilmiş olarak bildirildiği ortaya çıktı. (Görünüşe göre git tutarlı bir şekilde biten CRLF satırını dosyalara düzgün şekilde uygulamadığı için.)

Windows için en son git'e güncelledim ve sorunun gittiğini umuyorum.

Ben sadece yüzeyde emin olmasına rağmen benzer bir sorun. Her neyse, birisine yardımcı olabilir: yaptığım (FWIW, SourceTree'de): taahhüt edilmeyen dosyayı sakladı, sonra bir sıfırlama yaptı.

Diğer cevapların da belirttiği gibi, sorun satır sonu otomatik düzeltmeden kaynaklanmaktadır. * .Svg dosyalarıyla bu sorunla karşılaştım. Projemdeki simgeler için svg dosyası kullandım.

Bu sorunu çözmek için, sgg dosyalarının aşağıdaki satırı .gitattributes'e ekleyerek metin yerine ikili olarak ele alınması gerektiğini bildirin.

* .svg ikili

Benzer bir durumda. Hatların uçlarının farklı kodlarını (. Asp , .js, .css ... özü değil) tek bir dosyaya doldurabilen birçok programcıya yıllarca süren eziyetin bir sonucu olarak . Bir süre önce .gitattributes reddetti. Repo sol autorclf = trueve için ayarlar safecrlf = warn.

Son sorun arşivden farklı satır uçlarıyla senkronize edilirken ortaya çıktı. Arşivden kopyaladıktan sonra, git durumunda birçok dosya notla değiştirilir

The line will have its original line endings in your working directory. warning: LF will be replaced by CRLF in ...

Git'te çalışan ağaç satırı sonlarının normalleştirilmesi ile ilgili ipuçları ? yardım etti

git add -u

Karşılaştığım bir diğer olasılık, depodaki paketlerden birinin müstakil bir KAFA ile sonuçlanmasıydı. Buradaki yanıtların hiçbiri yardımcı olmazsa ve bunun gibi bir git durum mesajıyla karşılaşırsanız aynı sorunla karşılaşabilirsiniz:

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:   path/to/package (new commits)

A path/to/packageklasörüne gitmek git statusaşağıdaki sonucu vermelidir:

HEAD detached at 7515f05

Ve aşağıdaki komut daha sonra masteryerel şubenizle değiştirilmesi gereken sorunu çözmelidir:

git checkout master

Ayrıca, yerel şubenizin uzak şubenin arkasında bazı taahhütler olacağına dair bir mesaj alırsınız. git pullve ormanın dışında olmalısın!

Bazı sebeplerden dolayı

git add .

işe yaramadı , ama

$ git add -A

üstesinden geldi!