git durumu değişiklikleri gösterir, git checkout - <file> bunları kaldırmaz

Çalışma kopyamdaki tüm değişiklikleri kaldırmak istiyorum.
Çalışıyor git status, değiştirilen dosyaları gösterir.
Yaptığım hiçbir şey bu değişiklikleri kaldırmıyor.
Örneğin:

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")

Bu davranışa neden olabilecek birden fazla sorun vardır:

Satır sonu normalizasyonu

Ben de bu tür problemler yaşadım. Crlf'yi lf'ye otomatik olarak dönüştürmek için git'e iner. Bu genellikle tek bir dosyadaki karışık satır sonlarından kaynaklanır. Dosya dizinde normalleşir, ancak git çalışma ağacındaki dosyaya göre farklılaştırmak için git'i denormalize ettiğinde sonuç farklıdır.

Ancak bunu düzeltmek istiyorsanız, core.autocrlf dosyasını devre dışı bırakmalı , tüm satır sonlarını lf olarak değiştirmeli ve sonra tekrar etkinleştirmelisiniz. Veya aşağıdakileri yaparak tamamen devre dışı bırakabilirsiniz:

git config --global core.autocrlf false

Core.autocrlf yerine, .gitattributedosyaları kullanmayı da düşünebilirsiniz . Bu şekilde, repo kullanan herkesin aynı normalleştirme kurallarını kullandığından emin olabilirsiniz, böylece karma satır sonlarının depoya girmesini önleyebilirsiniz.

Geri dönülemez bir normalizasyon gerçekleştirildiğinde git'in sizi uyarmasını istiyorsanız core.safecrlf dosyasını uyarmak için de ayarlamayı düşünün .

Git manpages bunu söylüyor:

CRLF dönüşümü, verilerin bozulmasına yol açma şansına sahiptir. autocrlf = true, kesinleştirme sırasında CRLF'yi LF'ye ve ödeme sırasında LF'yi CRLF'ye dönüştürür. İşleme başlamadan önce LF ve CRLF karışımını içeren bir dosya git tarafından yeniden oluşturulamaz. Metin dosyaları için bu doğru olan şeydir: satır sonlarını düzeltir, böylece depoda yalnızca LF satır sonları olur. Ancak yanlışlıkla metin olarak sınıflandırılan ikili dosyalar için dönüşüm verileri bozabilir.

Büyük / küçük harfe duyarlı olmayan dosya sistemleri

Büyük / küçük harfe duyarlı olmayan dosya sistemlerinde, farklı kasa ile aynı dosya adı depoda olduğunda, git her ikisini de kontrol etmeye çalışır, ancak dosya sisteminde yalnızca bir tanesi bulunur. Git ikincisini karşılaştırmaya çalıştığında yanlış dosyayla karşılaştırır.

Çözüm, büyük / küçük harf duyarlı olmayan bir dosya sistemine geçiyor olabilir, ancak bu çoğu durumda uygun değildir veya yeniden adlandırılması ve başka bir dosya sistemindeki dosyalardan birini yeniden işlemesi değildir.

Windows'ta bu sorunu yaşıyordum, ancak kullanımın sonuçlarına bakmaya hazır config --global core.autocrlf falsedeğildim, aynı zamanda saklamamdaki diğer özel dalları ve güzellikleri terk edip taze bir klonla başlamaya hazır değildim. Sadece birţeyler yapmam gerek. Şimdi.

Git benim çalışma dizininizi tamamen yeniden yazmanıza izin verdiğiniz fikrinde bu benim için çalıştı:

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

( Orijinal soruya yapılan yorumlarda önerildiği gibi dosyaların çalıştırılmasının git reset --hardyeterince iyi olmadığını veya rmdosyalarda düz olmadığını unutmayın reset)

Metin seçeneklerinden hiçbiri benim için çalışmadığından, insanlar için işe yarayabilecek başka bir çözüm:

1. İçeriğini değiştirin .gitattributestek bir satır ile: * binary. Bu git'e her dosyaya hiçbir şey yapamayacağı ikili bir dosya gibi davranmasını söyler.
2. Sorun teşkil eden dosyalar için mesajın gittiğini kontrol edin; değilse, git checkout -- <files>onları depo sürümüne geri yükleyebilirsiniz
3. git checkout -- .gitattributes.gitattributesdosyayı ilk durumuna geri yüklemek için
4. Dosyaların hala değiştirilmiş olarak işaretlenip işaretlenmediğini kontrol edin.

Bu problemi olan gelecekteki insanlar için: Filemode değişikliklerine sahip olmak da aynı semptomlara sahip olabilir. git config core.filemode falsedüzeltir.

Bu beni çılgına çeviriyor, özellikle de çevrimiçi olarak herhangi bir çözüm bulunmadan bunu düzeltemedim. İşte böyle çözdüm. Bu bir meslektaşımın işi olduğu için burada kredi alamıyorum :)

Sorunun kaynağı: Git'i ilk yüklemem, pencerelerde otomatik satır dönüşümü olmadan yapıldı. Bu benim ilk GLFW taahhüdümün doğru satır sonu olmadan olmasına neden oldu.

Not: Bu yalnızca yerel bir çözümdür. Repoyu klonlayan bir sonraki adam hala bu problemle sıkışacak. Kalıcı bir çözüm burada bulunabilir: https://help.github.com/articles/dealing-with-line-endings/#re-normalizing-a-repository .

Kurulum: glfw projesi ile Xubuntu 12.04 Git repo

Sorun: Glfw dosyaları sıfırlanamıyor. Ne denediğimden bağımsız olarak daima değiştirilmiş olarak gösterilirler.

çözüldü:

edit .gitattributes

Comment out the line:    # text=auto

Save the file

restore .gitattributes:   git checkout .gitattributes

Aynı sorunu olan bir .bat dosyası vardı (izlenmemiş dosyalarda kurtulamadım). git checkout - işe yaramadı, bu sayfadaki önerilerin hiçbiri de işe yaramadı. Benim için işe yarayan tek şey yapmaktı:

git stash save --keep-index

Ve sonra zulayı silmek için:

git stash drop

Aynı sorunu iki kez aldım! Her iki kez saklamak bazı değişiklikler yaptım ve sonra onları geri pop çalıştı. Değişen bir sürü dosya var çünkü değişiklikleri pop - olabilir ama onlar DEĞİLDİR! Onlar tamamen aynı.

Şimdi yukarıdaki tüm çözümleri başarıyla denediğimi düşünüyorum. Denedikten sonra

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

Depomdaki hemen hemen tüm dosyaları değiştirdim.

Dosyayı dağıtırken, tüm satırları sildim ve sonra tekrar eklediğimi söylüyor.

Biraz rahatsız edici. Şimdi gelecekte saklanmaktan kaçınacağım ..

Tek çözüm yeni bir havuzu klonlamak ve baştan başlamaktır. (Geçen sefer yaptım)

Yapmayı deneyin

git checkout -f

Bu, mevcut çalışan yerel repodaki tüm değişiklikleri temizlemelidir

Bu sadece repo's .gitattributes dosyasını (ki tanımlanmış * text=autove *.c text) geçici olarak silerek düzeltmek mümkün .

Sildikten git statussonra koştum ve değişiklikler gitti. .Gitattributes tekrar yerleştirildikten sonra bile geri dönmediler.

Tutarlı çizgi sonlarına sahip olmak iyi bir şeydir. Örneğin, önemsiz de olsa gereksiz birleştirmeleri tetiklemez. Visual Studio'nun karışık satır sonlarına sahip dosyalar oluşturduğunu gördüm.

Ayrıca bash (linux üzerinde) gibi bazı programlar .sh dosyalarının LF sonlandırılmasını gerektirir.

Bunun olduğundan emin olmak için gitattributes kullanabilirsiniz. Autcrlf'nin değeri ne olursa olsun depo düzeyinde çalışır.

Örneğin, bunun gibi .gitattributes olabilir: * text = auto

Durumunuzda önemliyse, dosya türü / uzantısı başına daha spesifik olabilirsiniz.

Daha sonra autocrlf yerel olarak Windows programları için satır sonlarını dönüştürebilir.

Karışık bir C # / C ++ / Java / Ruby / R, Windows / Linux projesinde bu iyi çalışıyor. Şu ana kadar sorun yok.

Aynı belirtilerim vardı, ancak farklı bir şeyden kaynaklandım.

Yapacak durumda değildim:

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

üzerinde bile git rm --cached app.jssilinmiş olarak işaretler ve izlenmemiş dosyalarda app.js görebilirsiniz. Ama tekrar denediğimde rm -rf app.jsve git statushala bana 'izlenmemiş' dosyayı gösteriyor.

Meslektaşım ile birkaç denemeden sonra, Grunt neden olduğunu öğrendim!

Açık Gruntolduğundan ve app.js diğer birkaç js dosyasından oluşturulduğundan, js dosyaları (ayrıca bu app.js) ile yapılan her işlemden sonra app.js'yi yeniden oluşturduğunu öğrendik.

Bu sorun, repoya katkıda bulunan bir kişi bir Linux makinesinde çalıştığında veya Cygwin ve dosya izinlerine sahip pencereler değiştirildiğinde de oluşabilir. Git sadece 755 ve 644'ü biliyor.

Bu sorunun örneği ve nasıl kontrol edileceği:

git diff styleguide/filename

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

Bundan kaçınmak için git'i doğru şekilde ayarladığınızdan emin olmalısınız.

git config --global core.filemode false

Burada çok fazla çözüm var ve belki de kendi çözümümü bulmadan önce bunlardan bazılarını denemeliydim. Neyse burada bir tane daha ...

Bizim sorunumuz, son satırlar için herhangi bir yaptırımımızın olmadığı ve havuzun DOS / Unix'in bir karışımı olmasıydı. Daha da kötüsü, aslında bu pozisyonda açık kaynaklı bir repo olduğu ve çatallandığımız şeydi. İşletim sistemi deposunun birincil mülkiyeti olanlar tarafından tüm son satırları Unix olarak değiştirmeye karar verildi .gitattributesve satır sonlarını zorlamak için a'yı içeren taahhüt verildi .

Ne yazık ki bu bir kez DOS-2-Unix yapılmadan önce bir kod birleştirme nerede dosyaları sonsuza kadar değiştirildi olarak işaretlenmiş ve geri alınamadı burada açıklanan gibi sorunlara neden gibi görünüyordu.

Bunun için yaptığım araştırma sırasında karşılaştım - https://help.github.com/articles/dealing-with-line-endings/ - Bu sorunla tekrar karşılaşırsam, öncelikle bunu deneyerek başlayacağım.

İşte yaptım:

1. Başlangıçta bu sorunu yaşadığımı fark etmeden önce bir birleştirme yapmıştım ve bunu iptal etmek zorunda kaldım - git reset --hard HEAD( bir birleşme çatışmasıyla karşılaştım. Birleştirme işlemini nasıl iptal edebilirim? )

2. Söz konusu dosyaları VIM'de açtım ve Unix ( :set ff=unix) olarak değiştirdim . dos2unixElbette bunun gibi bir araç kullanılabilir

3. taahhüt

4. ile birleştirildi master(master DOS-2-Unix değişikliğine sahip)

   git checkout old-code-branch; git merge master

5. Çatışmalar çözüldü ve dosyalar tekrar :set ff=unixDOS'taydı. ( Https://github.com/itchyny/lightline.vim kurdum , bu da VIM durum satırında dosya biçiminin ne olduğunu görmeme izin verdi)

6. işledi. Tüm sıralama!

Karşılaştığım sorun, pencerelerin dosya adı büyük / küçük harflerini umursamaması, ancak git'in umurunda olması. Böylece git, dosyanın küçük ve büyük bir sürümünü depoladı, ancak yalnızca bir tanesini kullanıma alabilir.

Tüm değişiklikleri taahhüt ettim ve daha sonra taahhütte bulundum ve geri aldım. Bu benim için çalıştı

git ekleyin.

git commit -m "Rastgele kaydetme"

git reset --hard HEAD ~ 1

Normalde, GIT'de tüm değişikliklerinizi ve yeni dosyalarınızı temizlemek için aşağıdaki 2 komutun çok iyi çalışması gerekir ( DİKKATLİ olun , bu, oluşturmuş olabileceğiniz tüm yeni dosyalarınızı + klasörlerinizi siler ve değiştirilmiş tüm dosyalarınızı mevcut durumunuza geri yükler. taahhüt ):

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

Belki daha iyi bir seçenek bazen isteğe bağlı mesajla "git stash push" yapıyor, şöyle:

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

Bu, tüm yeni ve değiştirilmiş dosyalarınızı da temizler, ancak geri yüklemek istediğinizde bunların tümünü saklarsınız. GIT'te Stash, şubeden şubeye taşır, böylece isterseniz farklı bir şubede geri yükleyebilirsiniz.

Bir yan not olarak, yeni eklenen bazı dosyaları önceden hazırlamış ve onlardan kurtulmak istiyorsanız, bu hile yapmalıdır:

$ git reset --hard

Yukarıdakilerin hepsi sizin için işe yaramazsa , bir süre önce benim için neyin işe yaradığını aşağıda okuyun:

Daha önce birkaç kez bu problemle karşılaştım. Şu anda işverenim tarafından sağlanan Windows 10 makinesinde geliştiriyorum. Bugün, bu özel git davranışı, "geliştirme" dalımdan yeni bir dal oluşturmamdan kaynaklandı. Nedense, "geliştirme" dalına döndükten sonra, bazı rasgele dosyalar devam etti ve "git status" de "değiştirildi" olarak gösteriliyordu.

Ayrıca, bu noktada başka bir şubeye ödeme yapamadım, bu yüzden "geliştirme" şubemde kaldım.

Ben de öyle yaptım:

$ git log

Bugün "geliştirme" den oluşturduğum yeni dalın ilk "taahhüt" mesajında ​​gösterildiğini fark ettim, sonunda "HEAD -> geliştirme, kökeni / geliştirme, kökeni / HEAD, The-branch-i-create -veya-bugün ".

Gerçekten ihtiyacım olmadığından sildim:

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

Değiştirilen dosyalar hala görünüyordu, bu yüzden yaptım:

$ git stash

Bu benim sorunumu çözdü:

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

nothing to commit, working tree clean

Tabii ki $ git stash listsaklı değişiklikler gösterecek ve çok $ git stash clearazım olduğu ve herhangi bir saklamama ihtiyaç duymadığım için TÜM DURUMLARI SİLMEYE BAŞLADIM.

NOT : Birisinin benden önce burada önerdiği şeyi yapmayı denemedim:

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

Bu da işe yaramış olabilir, bir dahaki sefere bu sorunla karşılaştığımda denemek emin olacağım.

Bir havuzu klonlar ve bekleyen değişiklikleri anında görürseniz, depo tutarsız bir durumdadır. Açıklama DEĞİL Lütfen * text=autogelen .gitattributesdosyada. Havuzun sahibi, LF satır sonlarıyla tutarlı bir şekilde depolanan tüm dosyaları istediği için özel olarak buraya konuldu.

HankCa tarafından belirtildiği gibi, https://help.github.com/articles/dealing-with-line-endings/ adresindeki talimatları izleyerek sorunu çözmenin yolu budur. Kolay düğme:

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

Ardından şubeyi repo sahibiyle birleştirin (veya istekte bulunun).

Bu sayfadaki başka hiçbir şey işe yaramadı. Bu sonunda benim için çalıştı. İzlenmemiş veya kaydedilmiş dosya gösterilmiyor.

git add -A
git reset --hard

Benim için sorun, Visual Studio'nun komutu gerçekleştirirken açılmış olmasıydı.

git checkout <file>

Visual Studio kapatıldıktan sonra komut çalıştı ve sonunda çalışmalarımı yığınından uygulayabilirim. Bu nedenle, SourceTree, SmartGit, NotePad, NotePad ++ ve diğer editörler gibi kodunuzda değişiklik yapabilen tüm uygulamaları kontrol edin.

Şirketimizde de benzer bir durumla karşılaştık. Önerilen yöntemlerin hiçbiri bize yardımcı olmadı. Araştırma sonucunda sorun ortaya çıktı. Mesele Git'te iki dosya vardı, adları sadece sembollerin kaydında farklıydı. Unix sistemleri onları iki farklı dosya olarak gördü, ancak Windows deliriyordu. Sorunu çözmek için sunucudaki dosyalardan birini sildik. Bundan sonra, Windows'daki yerel depolarda birkaç komuta yardımcı oldu (farklı dizilerde):

git reset --hard
git pull origin
git merge

Bunu ekleyerek .git / config dosyasını düzenleyerek çözdüm:

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

Sonra .git / refs / heads / name_branch'a gittim ve son taahhüdün kimliğini yerleştirdimenter code here

Bu şekilde çözdüm:

1. İstediğiniz doğru kodun içeriğini kopyalayın
2. Soruna neden olan dosyayı (geri alamayacağınız dosyayı) diskinizden silin. şimdi aynı dosyanın silinmiş olarak işaretlenmiş her iki sürümünü de bulmalısınız.
3. Dosyaların silinmesini sağlayın.
4. Dosyayı aynı adla tekrar oluşturun ve 1. adımda kopyaladığınız doğru kodu yapıştırın
5. yeni dosyanın oluşturulmasını taahhüt eder.

Bu benim için işe yaradı.

Burada önerilen bir çözüm işe yaramadı, dosyanın aslında bazı özel karakterlere bir bağlantı olduğunu öğrendim:

% 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