trạng thái git hiển thị các sửa đổi, kiểm tra git - <file> không xóa chúng

Tôi muốn xóa tất cả các thay đổi đối với bản sao làm việc của tôi.
Chạy git statuscho thấy các tập tin sửa đổi.
Không có gì tôi làm dường như để loại bỏ những sửa đổi.
Ví dụ:

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

Có nhiều vấn đề có thể gây ra hành vi này:

Chuẩn hóa kết thúc dòng

Tôi cũng có những loại vấn đề này. Nó đi xuống git tự động chuyển đổi crlf sang lf. Điều này thường được gây ra bởi các kết thúc dòng hỗn hợp trong một tệp duy nhất. Tệp được chuẩn hóa trong chỉ mục, nhưng khi git sau đó không chuẩn hóa nó một lần nữa để khác với tệp trong cây làm việc, kết quả sẽ khác.

Nhưng nếu bạn muốn sửa lỗi này, bạn nên tắt core.autocrlf , thay đổi tất cả các kết thúc dòng thành lf, và sau đó kích hoạt lại. Hoặc bạn có thể vô hiệu hóa nó hoàn toàn bằng cách thực hiện:

git config --global core.autocrlf false

Thay vì core.autocrlf , bạn cũng có thể xem xét sử dụng .gitattributetệp. Bằng cách này, bạn có thể đảm bảo tất cả mọi người sử dụng repo đều sử dụng các quy tắc chuẩn hóa giống nhau, ngăn chặn các kết thúc dòng hỗn hợp đi vào kho lưu trữ.

Đồng thời xem xét việc đặt core.safecrlf để cảnh báo nếu bạn muốn git cảnh báo bạn khi việc chuẩn hóa không thể đảo ngược sẽ được thực hiện.

Các trang git nói điều này:

Chuyển đổi CRLF có một chút cơ hội làm hỏng dữ liệu. autocrlf = true sẽ chuyển đổi CRLF thành LF trong khi xác nhận và LF thành CRLF khi thanh toán. Một tệp có chứa hỗn hợp của LF và CRLF trước khi cam kết không thể được tạo lại bởi git. Đối với các tệp văn bản, đây là điều đúng đắn: nó sửa các kết thúc dòng sao cho chúng ta chỉ có các kết thúc dòng LF trong kho lưu trữ. Nhưng đối với các tệp nhị phân vô tình được phân loại là văn bản, việc chuyển đổi có thể làm hỏng dữ liệu.

Hệ thống tập tin không phân biệt chữ hoa chữ thường

Trên các hệ thống tệp không phân biệt chữ hoa chữ thường, khi cùng một tên tệp có vỏ khác nhau trong kho lưu trữ, git cố gắng kiểm tra cả hai, nhưng chỉ có một kết thúc trên hệ thống tệp. Khi git cố gắng so sánh cái thứ hai, nó sẽ so sánh nó với tệp sai.

Giải pháp có thể là chuyển sang hệ thống tệp không nhạy cảm trong trường hợp, nhưng điều này trong hầu hết các trường hợp là không khả thi hoặc đổi tên và cam kết một trong các tệp trên hệ thống tệp khác.

Tôi đã gặp vấn đề này trên Windows nhưng chưa sẵn sàng xem xét sự phân chia sử dụng. config --global core.autocrlf falseTôi cũng không sẵn sàng từ bỏ các chi nhánh và quà tặng riêng tư khác trong stash của mình và bắt đầu với một bản sao mới. Tôi chỉ cần làm một cái gì đó được thực hiện. Hiện nay.

Điều này làm việc cho tôi, với ý tưởng rằng bạn cho phép git viết lại thư mục làm việc của bạn hoàn toàn:

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

(Lưu ý rằng việc chạy git reset --hardkhông đủ tốt cũng như không rõ ràng rmtrên các tệp trước khi resetđược đề xuất trong các nhận xét cho câu hỏi ban đầu)

Một giải pháp khác có thể phù hợp với mọi người, vì không có tùy chọn văn bản nào phù hợp với tôi:

1. Thay thế nội dung .gitattributesbằng một dòng duy nhất : * binary. Điều này nói với git coi mọi tệp là tệp nhị phân mà nó không thể làm gì được.
2. Kiểm tra tin nhắn cho các tập tin vi phạm đã biến mất; nếu không, bạn có thể git checkout -- <files>khôi phục chúng về phiên bản kho lưu trữ
3. git checkout -- .gitattributesđể khôi phục .gitattributestập tin về trạng thái ban đầu
4. Kiểm tra xem các tập tin vẫn không được đánh dấu là đã thay đổi.

Đối với những người trong tương lai gặp vấn đề này: Có những thay đổi về tên tệp cũng có thể có các triệu chứng tương tự. git config core.filemode falsesẽ sửa nó

Điều này đã khiến tôi phát điên, đặc biệt là tôi không thể khắc phục điều này mà không có bất kỳ giải pháp nào được tìm thấy trực tuyến. Đây là cách tôi giải quyết nó. Không thể lấy tín dụng ở đây vì đây là công việc của một đồng nghiệp :)

Nguồn gốc của vấn đề: Cài đặt git ban đầu của tôi không có chuyển đổi dòng tự động trên windows. Điều này khiến cam kết ban đầu của tôi với GLFW không có kết thúc dòng thích hợp.

Lưu ý: Đây chỉ là một giải pháp địa phương. Anh chàng tiếp theo nhân bản repo vẫn sẽ bị mắc kẹt với vấn đề này. Một giải pháp lâu dài có thể được tìm thấy ở đây: https://help.github.com/articles/deals-with-line-endings/#re-n normalizing-a-reposeective .

Thiết lập: Repo Xubfox 12.04 với dự án glfw

Vấn đề: Không thể thiết lập lại các tập tin glfw. Chúng luôn hiển thị như đã sửa đổi, bất kể những gì tôi đã cố gắng.

Đã giải quyết:

edit .gitattributes

Comment out the line:    # text=auto

Save the file

restore .gitattributes:   git checkout .gitattributes

Tôi đã có một tệp .bat có cùng một vấn đề (không thể loại bỏ nó trong các tệp không bị theo dõi). kiểm tra git - không hoạt động, cũng không có bất kỳ đề xuất nào trên trang này. Điều duy nhất làm việc cho tôi là làm:

git stash save --keep-index

Và sau đó để xóa stash:

git stash drop

Có cùng một vấn đề hai lần! Cả hai lần khi thực hiện một số thay đổi tôi đã thực hiện và sau đó cố gắng đưa chúng trở lại. Không thể bật các thay đổi vì tôi đã có rất nhiều tệp được thay đổi - nhưng chúng KHÔNG! Họ đều giống hệt nhau.

Bây giờ tôi nghĩ rằng tôi đã thử tất cả các giải pháp trên mà không thành công. Sau khi thử

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

Bây giờ tôi đã có gần như tất cả các tập tin trong kho lưu trữ của tôi sửa đổi.

Khi phân biệt tệp, nó nói rằng tôi đã xóa tất cả các dòng và sau đó thêm chúng một lần nữa.

Kiểu quậy phá. Bây giờ tôi sẽ tránh đâm vào tương lai ..

Giải pháp duy nhất là sao chép một kho lưu trữ mới và bắt đầu lại. (Làm lần cuối)

Hãy thử làm một

kiểm tra git -f

Điều đó sẽ xóa tất cả các thay đổi trong repo cục bộ làm việc hiện tại

Tôi chỉ có thể khắc phục điều này bằng cách xóa tạm thời tệp .gitattribut của tôi (được xác định * text=autovà *.c text).

Tôi chạy git statussau khi xóa và sửa đổi đã biến mất. Họ đã không trở lại ngay cả sau khi .gitattribut được đưa trở lại vị trí.

Có kết thúc dòng nhất quán là một điều tốt. Ví dụ, nó sẽ không kích hoạt các sự hợp nhất không cần thiết, mặc dù tầm thường. Tôi đã thấy Visual Studio tạo các tệp có kết thúc dòng hỗn hợp.

Ngoài ra, một số chương trình như bash (trên linux) yêu cầu các tệp .sh bị chấm dứt.

Để đảm bảo điều này xảy ra, bạn có thể sử dụng gitattribut. Nó hoạt động ở cấp kho lưu trữ bất kể giá trị của autcrlf là gì.

Ví dụ: bạn có thể có .gitattribution như thế này: * text = auto

Bạn cũng có thể cụ thể hơn cho mỗi loại tệp / phần mở rộng nếu nó có vấn đề trong trường hợp của bạn.

Sau đó, autocrlf có thể chuyển đổi kết thúc dòng cho các chương trình Windows cục bộ.

Trên một dự án hỗn hợp C # / C ++ / Java / Ruby / R, Windows / Linux, điều này đang hoạt động tốt. Không có vấn đề cho đến nay.

Tôi cũng có các triệu chứng tương tự nhưng đã được gây ra bởi điều khác nhau.

Tôi không đủ thẩm quyền để:

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

ngay cả trên git rm --cached app.jsđó có dấu hiệu bị xóa và trong các tệp không bị theo dõi, tôi có thể thấy app.js. Nhưng khi tôi thử rm -rf app.jsvà làm git statuslại lần nữa, nó vẫn hiển thị cho tôi tệp trong 'không bị khóa'.

Sau vài lần thử với đồng nghiệp, chúng tôi đã phát hiện ra rằng nó đã được gây ra bởi Grunt!

Vì Gruntđã được bật và vì app.js đã được tạo từ một vài tệp js khác nên chúng tôi phát hiện ra rằng sau mỗi thao tác với các tệp js (cũng là app.js này) sẽ tạo lại app.js một lần nữa.

Vấn đề này cũng có thể xảy ra khi một người đóng góp cho repo hoạt động trên máy Linux hoặc các cửa sổ có Cygwin và quyền truy cập tệp được thay đổi. Git chỉ biết 755 và 644.

Ví dụ về vấn đề này và cách kiểm tra nó:

git diff styleguide/filename

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

Để tránh điều này, bạn nên đảm bảo rằng bạn thiết lập git chính xác bằng cách sử dụng

git config --global core.filemode false

Có rất nhiều giải pháp ở đây và có lẽ tôi nên thử một vài trong số đó trước khi tôi tự mình nghĩ ra. Dù sao ở đây là một ...

Vấn đề của chúng tôi là chúng tôi không có sự thực thi nào đối với các thiết bị đầu cuối và kho lưu trữ có sự pha trộn của DOS / Unix. Tệ hơn nữa là nó thực sự là một repo nguồn mở ở vị trí này và chúng tôi đã rẽ nhánh. Quyết định được đưa ra bởi những người có quyền sở hữu chính của kho lưu trữ hệ điều hành để thay đổi tất cả các dòng cuối sang Unix và cam kết được đưa ra bao gồm một .gitattributesđể thực thi các kết thúc dòng.

Thật không may, điều này dường như gây ra nhiều vấn đề giống như được mô tả ở đây khi một lần hợp nhất mã từ trước khi DOS-2-Unix được thực hiện, các tệp sẽ mãi mãi được đánh dấu là đã thay đổi và không thể hoàn nguyên.

Trong quá trình nghiên cứu về vấn đề này, tôi đã tình cờ gặp phải - https://help.github.com/articles/deals-with-line-endings/ - Nếu tôi gặp lại vấn đề này, trước tiên tôi sẽ bắt đầu bằng cách thử nó.

Đây là những gì tôi đã làm:

1. Ban đầu tôi đã thực hiện hợp nhất trước khi nhận ra tôi gặp vấn đề này và phải hủy bỏ nó - git reset --hard HEAD( Tôi gặp phải một cuộc xung đột hợp nhất. Làm cách nào tôi có thể hủy bỏ hợp nhất? )

2. Tôi đã mở các tệp được đề cập trong VIM và đổi thành Unix ( :set ff=unix). Một công cụ như dos2unixcó thể được sử dụng thay vì tất nhiên

3. cam kết

4. đã hợp nhất phần mastertrong (bản gốc có các thay đổi DOS-2-Unix)

   git checkout old-code-branch; git merge master

5. Đã giải quyết xung đột và các tệp lại là DOS vì vậy phải có :set ff=unixtrong VIM. (Lưu ý tôi đã cài đặt https://github.com/itchyny/lightline.vim cho phép tôi xem định dạng tệp trên dòng trạng thái VIM)

6. cam kết. Tất cả đã được sắp xếp!

Vấn đề mà tôi gặp phải là các cửa sổ không quan tâm đến việc viết hoa tên tệp, nhưng git thì có. Vì vậy, git đã lưu trữ một phiên bản chữ thường và chữ hoa của tệp nhưng chỉ có thể kiểm tra một phiên bản.

Tôi đã cam kết tất cả các thay đổi và sau đó đã thực hiện và hoàn tác trên cam kết. Điều này làm việc cho tôi

git thêm.

git commit -m "Cam kết ngẫu nhiên"

thiết lập lại git - đầu trang ~ 1

Thông thường, trong GIT để xóa tất cả các sửa đổi và tệp mới của bạn, 2 lệnh sau sẽ hoạt động rất độc đáo (là CAREFUL , thao tác này sẽ xóa tất cả các tệp mới + thư mục bạn có thể đã tạo và sẽ khôi phục tất cả các tệp đã sửa đổi của bạn về trạng thái hiện tại của bạn cam kết ):

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

Có thể một tùy chọn tốt hơn đôi khi chỉ là thực hiện "git stash đẩy" với thông báo tùy chọn, như vậy:

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

Điều này cũng sẽ xóa tất cả các tệp mới và sửa đổi của bạn, nhưng bạn sẽ có tất cả chúng được lưu trong trường hợp bạn muốn khôi phục chúng. Stash trong GIT mang từ chi nhánh này sang chi nhánh khác, vì vậy bạn có thể khôi phục chúng ở một chi nhánh khác, nếu bạn muốn.

Lưu ý phụ, trong trường hợp bạn đã dàn dựng một số tệp mới được thêm vào và muốn loại bỏ chúng, thì nên thực hiện thủ thuật:

$ git reset --hard

Nếu tất cả những điều trên không phù hợp với bạn , hãy đọc phần bên dưới những gì đã làm cho tôi một lúc trước:

Tôi đã gặp vấn đề này vài lần trước đây. Tôi hiện đang phát triển trên máy Windows 10 do nhà tuyển dụng của tôi cung cấp. Hôm nay, hành vi git đặc biệt này là do tôi tạo ra một nhánh mới từ nhánh "phát triển" của mình. Vì một số lý do, sau khi tôi chuyển trở lại nhánh "phát triển", một số tệp dường như ngẫu nhiên vẫn tồn tại và hiển thị là "đã sửa đổi" trong "trạng thái git".

Ngoài ra, tại thời điểm đó tôi không thể kiểm tra một chi nhánh khác, vì vậy tôi đã bị mắc kẹt trên chi nhánh "phát triển" của mình.

Đây là những gì tôi đã làm:

$ git log

Tôi nhận thấy rằng nhánh mới mà tôi đã tạo từ "phát triển" trước đó ngày hôm nay đã hiển thị trong thông báo "cam kết" đầu tiên, được tham chiếu ở cuối "ĐẦU -> phát triển, nguồn gốc / phát triển, nguồn gốc / Đầu, nhánh-i-tạo -earlier-hôm nay ".

Vì tôi không thực sự cần nó, tôi đã xóa nó:

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

Các tập tin thay đổi vẫn hiển thị, vì vậy tôi đã làm:

$ git stash

Điều này đã giải quyết vấn đề của tôi:

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

nothing to commit, working tree clean

Tất nhiên $ git stash listsẽ hiển thị các thay đổi được lưu trữ và vì tôi đã có một vài và không cần bất kỳ $ git stash cleardấu vết nào của mình, tôi đã làm để XÓA TẤT CẢ CÁC GIAI ĐOẠN.

LƯU Ý : Tôi chưa thử làm những gì mà ai đó đề xuất ở đây trước tôi:

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

Điều này có thể cũng đã hoạt động, tôi chắc chắn sẽ thử nó lần tới khi tôi gặp phải vấn đề này.

Nếu bạn sao chép một kho lưu trữ và ngay lập tức thấy các thay đổi đang chờ xử lý, thì kho lưu trữ ở trạng thái không nhất quán. Vui lòng KHÔNG bình luận * text=autotừ .gitattributestập tin. Điều đó được đặt ở đó một cách cụ thể bởi vì chủ sở hữu của kho lưu trữ muốn tất cả các tệp được lưu trữ nhất quán với các kết thúc dòng LF.

Như HankCa đã nêu, làm theo các hướng dẫn trên https://help.github.com/articles/deals-with-line-endings/ là cách để khắc phục sự cố. Nút dễ dàng:

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

Sau đó hợp nhất (hoặc kéo yêu cầu) chi nhánh cho chủ sở hữu của repo.

Không có gì khác trên trang này làm việc. Điều này cuối cùng đã làm việc cho tôi. Hiển thị không có tập tin không bị theo dõi, hoặc cam kết.

git add -A
git reset --hard

Đối với tôi, vấn đề là Visual Studio đã được mở khi thực hiện lệnh

git checkout <file>

Sau khi đóng Visual Studio, lệnh đã hoạt động và cuối cùng tôi có thể áp dụng công việc của mình từ ngăn xếp. Vì vậy, hãy kiểm tra tất cả các ứng dụng có thể thay đổi mã của bạn, ví dụ SourceTree, SmartGit, NotePad, NotePad ++ và các trình soạn thảo khác.

Chúng tôi phải đối mặt với một tình huống tương tự trong công ty của chúng tôi. Không có phương pháp đề xuất nào không giúp chúng tôi. Kết quả của nghiên cứu, vấn đề đã được tiết lộ. Có điều là trong Git có hai tệp, tên của chúng chỉ khác nhau trong thanh ghi ký hiệu. Các hệ thống Unix thấy chúng là hai tệp khác nhau, nhưng Windows đang phát điên. Để giải quyết vấn đề, chúng tôi đã xóa một trong các tệp trên máy chủ. Sau đó, tại các kho lưu trữ cục bộ trên Windows đã giúp một số lệnh tiếp theo (theo các trình tự khác nhau):

git reset --hard
git pull origin
git merge

Tôi đã giải quyết nó bằng cách chỉnh sửa .git / config, thêm:

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

Sau đó, tôi đã đi đến .git / refs / Heads / name_branch và đặt id của lần xác nhận cuối cùngenter code here

Tôi đã giải quyết nó theo cách này:

1. Sao chép nội dung của mã chính xác mà bạn muốn
2. Xóa tệp gây ra sự cố (tệp mà bạn không thể hoàn nguyên) khỏi đĩa của mình. bây giờ bạn sẽ tìm thấy cả hai phiên bản của cùng một tệp được đánh dấu là đã bị xóa.
3. Cam kết xóa các tập tin.
4. Tạo lại tệp với cùng tên và dán đúng mã bạn đã sao chép ở bước 1
5. cam kết tạo tập tin mới.

Đó là những gì làm việc cho tôi.

Một giải pháp được đề xuất ở đây không hoạt động, tôi phát hiện ra tệp thực sự là một liên kết đến một số ký tự đặc biệt:

% 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