Git'teki değişiklikleri göz ardı edemiyorum


125

Komut satırından aşağıdakileri gördükten sonra:

# On branch RB_3.0.10
# 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:   index.htm

Şu komutu yazarak değişikliklerimi atmaya çalışıyorum:

git checkout -- index.htm

ancak git status'u yeniden çalıştırdığımda tamamen aynı görünüyor. Ödeme çalışmıyor gibi görünüyor. Yanlış bir şey mi yapıyorum? Windows / cygwin'de GIT 1.6.1.2 kullanıyorum.

# On branch RB_3.0.10
# 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:   index.htm

4
Mu git checkout HEAD -- index.htmişler (yerine endeksi dışarı kontrol etme gereğini son kararlı durumdan kontrol)?
Jakub Narębski

3
git checkout HEAD -- index.htmbenim için çalıştı!
Ben Tideswell

Yanıtlar:


52

Bu beni bir süredir rahatsız ediyordu, hemen hemen kontrol ettiğim her repoda göz ardı edemediğim değişiklikler vardı. Uzun lafın kısası, yukarıdakilerin hepsini denedim, hiçbir şey işe yaramadı. İşleri normale döndürmek için yaptığım şey buydu (Mac'te):

Completely remove the autocrlf & safecrlf settings from ~/.gitconfig
Completely remove the autocrlf & safecrlf settings from your repo's local config ./.git/config
git rm --cached -r .
git reset --hard

7
Yukarıdaki her şeyi denedikten sonra, benim için işe
Anders

Teşekkür ederim! Anders'in söylediği gibi, bu çözüm benim için de çalışıyor. Autocrlf'i # autocrlf ile değiştirdim
David

37

İşte benim deneyimim, aşağıdaki değişkenleri ayarlayın .git/config:

[core]
    autocrlf = false
    safecrlf = false
    eol = crlf

sonra çalıştırın $ git checkout HEAD .ve çalışır. ama $ git checkout -- .değil, garip!

* git sürüm 1.9.3


35

git diffDosyada hangi değişiklikler gösteriliyor? Windows'ta, bunun gibi sorunlara neden olan satır sonlarıyla ilgili sorunlar gördüm. Bu durumda, sizin için var hangi ayarları bakmak git config core.autocrlfve git config core.safecrlf. Burada bu ayarlar için bazı belgeler var .

git svnSubversion ile entegrasyon için kullanıyorsanız , autocrlfkapalı olduğundan emin olun . Anlayabildiğim kadarıyla, bu konfigürasyonda sadece bozuk ve checkoutherhangi bir değişikliği geri almak için bir yaptığınızda , araçların çoğunun dosyaların değiştirildiğini düşünmesine neden oluyor .

Bulduğunuz yerde bir sorun görüyorsanız git checkoutve daha sonra git statusdosyanın hala değiştirildiğini ve git diffdosyanın her satırında değiştirildiğini gösteriyorsa, gördüğünüz sorun budur.

core.autocrlf

True ise git, metin dosyalarındaki satırların sonundaki CRLF'yi dosya sisteminden okurken LF'ye dönüştürür ve dosya sistemine yazarken tersine dönüştürür. Değişken giriş olarak ayarlanabilir, bu durumda dönüştürme yalnızca dosya sisteminden okurken gerçekleşir, ancak dosyalar satırların sonunda LF ile yazılır. Şu anda, hangi yolların "metin" olarak değerlendirileceğine (yani, otocrlf mekanizmasına tabi tutulacağına) tamamen içeriğe dayalı olarak karar verilmektedir.

core.safecrlf

True ise git, CRLF'yi core.autocrlf tarafından kontrol edildiği şekilde dönüştürmenin tersine çevrilebilir olup olmadığını kontrol eder. Git, bir komutun çalışma ağacındaki bir dosyayı doğrudan veya dolaylı olarak değiştirip değiştirmediğini doğrulayacaktır. Örneğin, bir dosyayı işlemek ve ardından aynı dosyayı teslim almak, çalışma ağacındaki orijinal dosyayı vermelidir. Geçerli core.autocrlf ayarı için durum bu değilse, git dosyayı reddeder. Değişken "warn" olarak ayarlanabilir, bu durumda git yalnızca geri döndürülemez bir dönüşüm konusunda uyarır ancak işleme devam eder. ...


core.autocrlf = gerçek core.safecrlf ayarlanmadı. Windows için bu doğru olarak ayarlanmalı mı? İkisi arasındaki fark nedir?

Git svn kullanıyorsanız ikisini de kapalı bırakın derim. Biraz daha detay ekledim.
1800 BİLGİ

4
Onu en az 90 derece döndürmeyi kastettiğini varsayıyorum
vijrox

2
Hem core.autocrlf hem de core.safecrlf'i true olarak ayarladığımda, 'git reset --hard HEAD' komutunu çalıştırarak sorun teşkil eden dosyalarda tespit edilen değişiklikleri göz ardı edebildim.
Aleksey

19

Bence geçmen gerek -f

Man sayfasından ( man git-checkout, GIT-CHECKOUT (1)):

-f, --force
Dizin veya çalışma ağacı HEAD'den farklı olsa bile devam eder.
Bu, yerel değişiklikleri atmak için kullanılır .

Örneğin, mevcut daldaki değişiklikleri atın ve farklı bir şubeye geçin:

git checkout -f master

7
Neye geçiş? Cevabı tamamlamak güzel olurdu
PandaWood

@Matt Niyetim farklı bir şubeyi kontrol etmek değildi. Gerçekten hatırlamıyorum ama söz bakılırsa kalmamak cevap 2009'dan olduğunu, ben geçmek anlamına düşünüyorum -fçıkış için - <filename> olduğu gibigit checkout -f -- filename
Hasen

@hasen Açıklamak için sorduğunuz üç yorum, bu yüzden "örneğin" ekledim. Örnek, diğer kullanımları engellemiyor-f
Matt H

Benim için çalıştı. git checkout -f master"Zaten 'usta" yı attı ama değişiklikler gitti.
Hıristiyan

12

@ 1800 bilgilerinin önerdiği gibi satır sonları olabilir, ancak başka bir olasılık da (bu, bu dosyaları bir teslim alma komutuyla geri döndürmenizi engelleyen) dosya modundan biridir. Bana olan da buydu. Benim versiyonumda bunu kullanarak keşfedebilirsiniz

git diff index.htm

Ve size dosya modu değişikliklerini gösterecektir. Yine de, -f seçeneğiyle bile, kullanıma alma özelliğini kullanarak onları geri döndürmenize izin vermez. Bunun için ikisini de kullanın

git config core.filemode yanlış

veya metin düzenleyicinizde git .config'inizi değiştirerek

[Çekirdek]

filemode = false

Bunu yaptıktan sonra kullanabilirsiniz

git reset KAFA index.htm

ve dosya kaybolmalıdır.

(Bunların hepsini git yok sayma modu değişikliklerini nasıl yapabilirim (chmod)? Ve güncelleme-dosya-izinleri-only-in-git cevaplarından aldım )


Çok teşekkürler! Dosya modu değişikliklerinden kurtulmam için diğer önerilerin hiçbiri işe yaramadı.
Thorkil Værge

6

OSX veya Windows'ta mısınız? Eğer öyleyse, sorun muhtemelen aynı isimde, farklı büyük / küçük harflere sahip iki dosyaya sahip olmaktır. Örneğin. index.htm ve Index.htm

Windows ve varsayılan olarak OSX, büyük / küçük harfe duyarlı git ile çakışan büyük / küçük harfe duyarlı olmayan bir dosya sistemi kullanır.


2

Bu sorunu yaşadım ve yukarıdakilerin hepsini denedikten sonra hiçbir şey işe yaramadı.

Benim için işe yarayan şey, dosyanın bulunduğu dizini silmekti, sonra yaptı git statusve o dizindeki tüm dosyaların artık silinmiş olarak işaretlendiğinden emin olmaktı. Ondan sonra basitçe yaptım git checkout -fve her şey normale döndü.


1

Üzerinde bir libGDXproje üzerinde çalışıyordum Android Studiove yaptığım tüm değişiklikleri atmak istedim ve benim için hiçbir şey işe yaramadı, bulduğum çözüm tüm değişiklikleri yeni bir şubeye aktarmaktı.

git checkout -b TRASH
git add .
git commit -m "discarded changes"
git checkout master

ve sonra isterseniz TRASHşubeyi silebilirsiniz .


1

Aynı sorunu yaşadım, yukarıdaki yorumlardan hiçbiri işe yaramadı. Dosya sistemimin büyük / küçük harfe duyarlı olmadığı (varsayılan osx, ancak pencereler muhtemelen aynı şekilde davranır) ve aynı dizinde farklı içeriğe sahip hem büyük hem de küçük harfli bir dosya bulunduğu ortaya çıktı. Bilgisayarımda her iki isim de aynı dosyayı gösterdiğinden, git status ne yaparsam yapayım her zaman bir değişiklik gösterdi. Sorunu çözmek için:

  • Dosyalardan birini başka bir bilgisayardan kaldırmam ve depoya itmem gerekiyordu

  • tüm yerel sürümü tamamen silin

  • sıfırdan git klonu yap


0

Var olmayan veya değiştirilmiş dosyaları atmama izin vermeyen benzer bir sorun yaşadım. Visual Studio'yu işte kullanıyorum ve bunun uygulama çalışırken dalları değiştirirken olduğunu buldum.

git checkoutve atmaya çalışmak yardımcı olmadı. İşe yaramazdı ya da bana sadece iznim olmadığını söylerdi.

İşe yarayan çözüm:

  1. Gidin Güvenli Mod
  2. Dosyaları sil

Yeniden başlamak bir acıdır, ancak bu 100 şeyi denemekten daha hızlı çalıştı.


0

Kolay bir çözüm var. Bu olursa (normalde beklenmedik pencere kapanması veya bellek dökümü nedeniyle) ve değişikliklerinizi atamaz ve hatta dallar arasında geçiş yapamazsınız (Git, yeterli izniniz olmadığını söylüyor); içinde Windowsçevre show all hidden files and foldersklasör seçeneklerinden. GIT dizininize gidin (ile başlamalıdır .git) ve "index.lock"dosyayı silin . O zaman Git yapmak istediğinizi yapmanıza izin vermelidir.


0

Bazılarından kurtulmak için a ve git stashardından a yaptım git stash clean. .Git / veya ~ / .git öğelerinde herhangi bir otomatik cr / lf yapılandırması görmedim.


0

Benim durumumda, bir dizinle ilgili değişiklikleri göz ardı edemedim. örneğin git diff çalıştırdığımda şunu görürdüm: -Subproject commit fdcccccccccccccccccccccccccccccccccccccc +Subproject commit f1bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb

Bu yüzden o dizini aradım ve orada bir git durumu çalıştırdım. HEAD bağımsız bir durumdaydı. Ve sonra git checkout masteroraya koştum . Bu benim için işleri yoluna koydu. Ancak bu, burada sorulan tam senaryo için yararlı değildir.


0

Bu eski bir soru, ama yine de benimle ilgiliydi. Cevabımı ofiste sorana kadar bulamadım ve sorunun alt modüllerde olduğunu keşfettim. Güncellendiklerinde ve kendi deponuz bu değişiklikleri yansıtmadığında, farklılıklar varmış gibi görünür, başın sıfırlanması yardımcı olmaz. Bu durumda, şunu çalıştırın:

git status update

Bu , işleri düzeltmeye yardımcı olmalı (bu özel durumda)


0

Windows'ta bir izin sorunum vardı icacls containingFolder /reset /t /l /cve izinlerimi geri almak için bunu yapmam ve ardından klasöre çift tıklamam gerekiyordu.


0

Aşağıdaki içeriğe sahip .git özniteliklerim vardı:

* text=auto eol=lf

Sorunun üstesinden gelmek için, .gitattributessatır sonlarını rahatlatan bu satırı kaldırarak düzenleyin . Ardından git reset --hard HEADdosyaları ve .gitattributesdosyayı geri aldı .


0

Benim için bu sorun, Netlify CMS aracılığıyla yüklenen ve Netlify Large Media işleyicisi tarafından farklı şekilde sunulan bir Git-LFS görüntüsünün indirilmesinin bir kombinasyonuyla ortaya çıktı.

Çözümüm, ~/.gitconfigaşağıdaki gibi görünmeleri için bu satırları yorumlamak / kaldırmak ve ardından git statustekrar kontrol etmekti .

# [filter "lfs"]
#   clean = git-lfs clean %f
#   smudge = git-lfs smudge %f
#   required = true

VEYA muhtemelen .gitconfigrepo kökünde a aracılığıyla daha yerel bir filtre ekleyebilir ve bir şekilde orada lfs için filtre kurallarının üzerine yazabilirsiniz.

Umarım bu bir arkadaşa yardımcı olur.


-1

Ben de benzer bir sorunla karşılaştım ve aşağıdaki adımlar bana yardımcı oldu:

git commit -am 'temp commit'
git pull origin master
git reset head~1
git reset head --hard

Umarım diğer insanlara da yardımcı olur.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.