Sau đó git reset --hard, git statusđưa cho tôi các tập tin trong Changes not staged for commit:phần.

Tôi cũng đã thử git reset ., git checkout -- .và git checkout-index -f -a, vô ích.

Vì vậy, làm thế nào tôi có thể thoát khỏi những thay đổi không có căn cứ?

Điều này dường như chỉ đạt các tập tin dự án Visual Studio. Kỳ dị. Xem dán này: http://pastebin.com/eFZwPn9Z . Điều đặc biệt với các tệp đó là trong .gitattribut tôi có:

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

Ngoài ra, autocrlfđược đặt thành false trong toàn cầu của tôi .gitconfig. Điều đó có thể có liên quan?

Tôi đã có cùng một vấn đề và nó có liên quan đến .gitattributestập tin. Tuy nhiên, loại tệp gây ra sự cố không được chỉ định trong .gitattributes.

Tôi đã có thể giải quyết vấn đề bằng cách chạy

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

GIẢI QUYẾT !!!

Tôi đã giải quyết vấn đề này bằng các bước sau

1) Xóa mọi tệp khỏi chỉ mục của Git.

git rm --cached -r .

2) Viết lại chỉ mục Git để chọn tất cả các kết thúc dòng mới.

git reset --hard

Giải pháp là một phần của các bước được mô tả trên trang web git https://help.github.com/articles/deals-with-line-endings/

Git sẽ không thiết lập lại các tập tin không có trên kho lưu trữ. Vì vậy, bạn có thể:

$ git add .
$ git reset --hard

Điều này sẽ tạo ra tất cả các thay đổi, điều này sẽ khiến Git nhận thức được các tệp đó và sau đó đặt lại chúng.

Nếu điều này không hiệu quả, bạn có thể cố gắng bỏ và bỏ các thay đổi của mình:

$ git stash
$ git stash drop

Nếu bạn sử dụng Git cho Windows, đây có thể là vấn đề của bạn

Tôi đã có cùng một vấn đề và stash, thiết lập lại cứng, làm sạch hoặc thậm chí tất cả trong số họ vẫn còn để lại những thay đổi phía sau. Vấn đề hóa ra là chế độ tập tin x không được git đặt đúng. Đây là một "vấn đề đã biết" với git cho windows. Các thay đổi cục bộ hiển thị ở trạng thái gitk và git là chế độ cũ 100755 chế độ mới 100644, không có bất kỳ sự khác biệt nào về tệp thực tế.

Cách khắc phục là bỏ qua chế độ tập tin:

git config core.filemode false

Thêm thông tin ở đây

Được rồi, tôi đã giải quyết vấn đề.

Có vẻ như các .gitattributestập tin, có chứa:

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

làm cho các tập tin dự án xuất hiện không được tổ chức. Tôi không biết tại sao lại như vậy, và tôi thực sự hy vọng rằng ai đó biết cách sử dụng git sẽ cho chúng tôi một lời giải thích hay.

Cách khắc phục của tôi là xóa các tệp này và thêm vào autocrlf = falsebên dưới .[core].git/config

Điều này không hoàn toàn giống với cấu hình trước đó, vì nó yêu cầu mọi nhà phát triển phải có autocrlf = false. Tôi muốn tìm một sửa chữa tốt hơn.

BIÊN TẬP:

Tôi đã nhận xét các dòng liên quan, không ghi chú chúng và nó đã làm việc. Cái gì ... tôi thậm chí không ...!

Nguyên nhân có thể # 1 - Chuẩn hóa kết thúc dòng

Một tình huống có thể xảy ra là khi tệp được đề cập đã được kiểm tra vào kho lưu trữ mà không có cấu hình chính xác cho các kết thúc dòng (1) dẫn đến một tệp trong kho lưu trữ có đầu cuối dòng không chính xác hoặc kết thúc dòng hỗn hợp. Để xác nhận, xác minh rằng git diffchỉ hiển thị các thay đổi trong kết thúc dòng (theo mặc định có thể không hiển thị các thay đổi này, hãy thử git diff | cat -vxem trả về vận chuyển dưới dạng ^Mký tự bằng chữ ).

Sau đó, ai đó có thể đã thêm .gitattributeshoặc sửa đổi core.autocrlfcài đặt để bình thường hóa kết thúc dòng (2). Dựa trên .gitattributescấu hình toàn cầu hoặc toàn cầu, Git đã áp dụng các thay đổi cục bộ cho bản sao làm việc của bạn áp dụng chuẩn hóa kết thúc dòng được yêu cầu. Thật không may, vì một số lý do git reset --hardkhông hoàn tác những thay đổi chuẩn hóa dòng này.

Giải pháp

Cách giải quyết trong đó các kết thúc dòng cục bộ được đặt lại sẽ không giải quyết được vấn đề. Mỗi khi tập tin được "nhìn thấy" bởi git, nó sẽ thử và áp dụng lại chuẩn hóa, dẫn đến cùng một vấn đề.

Tùy chọn tốt nhất là để git áp dụng chuẩn hóa mà nó muốn bằng cách chuẩn hóa tất cả các kết thúc dòng trong repo để khớp với .gitattributes và thực hiện các thay đổi đó - xem Cố gắng sửa các kết thúc dòng bằng nhánh lọc git, nhưng không gặp may .

Nếu bạn thực sự muốn thử và hoàn nguyên các thay đổi cho tệp theo cách thủ công thì giải pháp đơn giản nhất dường như là xóa các tệp đã sửa đổi, và sau đó nói với git để khôi phục chúng, mặc dù tôi lưu ý rằng giải pháp này dường như không hoạt động ổn định 100% thời gian ( CẢNH BÁO: KHÔNG chạy cái này nếu các tệp đã sửa đổi của bạn có các thay đổi khác với kết thúc dòng !!):

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

Lưu ý rằng, trừ khi bạn bình thường hóa các kết thúc dòng trong kho lưu trữ tại một số điểm, bạn sẽ tiếp tục gặp phải vấn đề này.

Nguyên nhân có thể # 2 - Trường hợp không nhạy cảm

Nguyên nhân thứ hai có thể là sự không nhạy cảm trường hợp trên Windows hoặc Mac OS / X. Ví dụ: giả sử một đường dẫn như sau tồn tại trong kho lưu trữ:

/foo/bar

Bây giờ ai đó trên Linux cam kết các tệp vào /foo/Bar(có thể là do công cụ xây dựng hoặc thứ gì đó đã tạo thư mục đó) và đẩy. Trên Linux, đây thực sự là hai thư mục riêng biệt:

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

Kiểm tra repo này ra trên Windows hoặc Mac có thể dẫn đến biến đổi fileAmà không thể được đặt lại, vì trên mỗi thiết lập lại, git trên Windows để kiểm tra /foo/bar/fileA, và sau đó vì Windows là trường hợp nhạy cảm, ghi đè nội dung của fileAvới/foo/Bar/fileA , kết quả là họ bị "biến dạng".

Một trường hợp khác có thể là (các) tệp riêng lẻ tồn tại trong repo, khi được kiểm tra trên một hệ thống tệp không nhạy cảm trường hợp, sẽ chồng lấp. Ví dụ:

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

Có thể có những tình huống tương tự khác có thể gây ra vấn đề như vậy.

git về trường hợp hệ thống tập tin không nhạy cảm thực sự sẽ phát hiện tình huống này và hiển thị một thông báo cảnh báo hữu ích, nhưng hiện tại thì không (điều này có thể thay đổi trong tương lai - xem cuộc thảo luận này và các bản vá được đề xuất có liên quan trên danh sách gửi thư của git.git).

Giải pháp

Giải pháp là đưa trường hợp của các tệp trong chỉ mục git và trường hợp trên hệ thống tệp Windows vào căn chỉnh. Điều này có thể được thực hiện trên Linux, nó sẽ hiển thị trạng thái thực sự của mọi thứ, HOẶC trên Windows với tiện ích nguồn mở rất hữu ích Git-Unite . Git-Unite sẽ áp dụng các thay đổi trường hợp cần thiết cho chỉ số git, sau đó có thể được cam kết với repo.

(1) Đây là khả năng nhất bởi người sử dụng Windows, mà không cần bất kỳ .gitattributesđịnh nghĩa cho các tập tin trong câu hỏi, và sử dụng các thiết lập mặc định toàn cầu cho core.autocrlfđó làfalse (xem (2)).

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

Nếu các câu trả lời khác không hoạt động, hãy thử thêm các tệp, sau đó đặt lại

$ git add -A
$ git reset --hard

Trong trường hợp của tôi, điều này có ích khi có một loạt các tệp trống mà git đang theo dõi.

Một nguyên nhân khác cho điều này có thể là hệ thống tệp không phân biệt chữ hoa chữ thường . Nếu bạn có nhiều thư mục trong repo của mình ở cùng cấp có tên chỉ khác nhau tùy theo từng trường hợp, bạn sẽ bị ảnh hưởng bởi điều này. Duyệt kho lưu trữ nguồn bằng giao diện web của nó (ví dụ: GitHub hoặc VSTS) để đảm bảo.

Để biết thêm thông tin: https://stackoverflow.com/a/2016426/67824

Bạn có thể stashloại bỏ các thay đổi của mình, sau đó thả stash:

git stash
git stash drop

Không có phương pháp nào trong số này làm việc cho tôi, giải pháp duy nhất là nuke toàn bộ repo và sao chép lại nó. Điều này bao gồm stashing, đặt lại, thêm rồi đặt lại, cài đặt clrf, độ nhạy trường hợp, vv Thở dài ..

Chạy lệnh sạch :

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

git clean -fd

Kiểm tra của bạn .gitattributes.

Trong trường hợp của tôi, tôi có *.js text eol=lftrong đó và tùy chọn git core.autocrlflà true.

Nó đưa tôi đến tình huống khi git tự động chuyển đổi các kết thúc dòng tệp của tôi và ngăn tôi sửa nó và thậm chí git reset --hard HEADkhông làm gì cả.

Tôi sửa nó bằng nhận xét *.js text eol=lftrong tôi .gitattributesvà không chú ý đến nó sau nó.

Hình như nó chỉ là ma thuật.

Tôi gặp phải một vấn đề tương tự cũng liên quan .gitattributes, nhưng đối với trường hợp của tôi liên quan đến LFS của GitHub. Mặc dù điều này không chính xác là kịch bản của OP, tôi nghĩ rằng nó cung cấp một cơ hội để minh họa những gì .gitattributestập tin làm và tại sao nó có thể dẫn đến những thay đổi không được thể hiện dưới dạng khác biệt "ảo".

Trong trường hợp của tôi, một tệp đã có trong kho lưu trữ của tôi, giống như từ đầu thời gian. Trong một cam kết gần đây, tôi đã thêm một git-lfs trackquy tắc mới bằng cách sử dụng một mẫu có tầm nhìn hơi rộng, và cuối cùng phù hợp với tệp cổ này. Tôi biết tôi đã không muốn thay đổi tập tin này; Tôi biết rằng tôi đã không thay đổi tập tin, nhưng bây giờ nó là trong những thay đổi chưa được thực hiện của tôi và không có số lượng kiểm tra hoặc thiết lập lại cứng trên tập tin đó sẽ sửa nó. Tại sao?

Tiện ích mở rộng GitHub LFS hoạt động chủ yếu thông qua việc tận dụng các hook gitcung cấp quyền truy cập thông qua .gitattributestệp. Nói chung, các mục trong .gitattributeschỉ định cách xử lý tệp phù hợp. Trong trường hợp của OP, nó liên quan đến việc bình thường hóa kết thúc dòng; trong tôi, đó là liệu có để LFS xử lý việc lưu trữ tệp hay không. Trong cả hai trường hợp, tệp thực sự gitnhìn thấy khi tính toán a git diffkhông khớp với tệp mà bạn thấy khi bạn kiểm tra tệp. Do đó, nếu bạn thay đổi cách xử lý tệp thông qua .gitattributesmẫu phù hợp với nó, nó sẽ hiển thị dưới dạng các thay đổi chưa được xử lý trong báo cáo trạng thái, ngay cả khi thực sự không có thay đổi trong tệp.

Tất cả những gì đã nói, "câu trả lời" của tôi cho câu hỏi là nếu thay đổi trong .gitattributestệp là điều bạn muốn làm, bạn thực sự chỉ nên thêm các thay đổi và tiếp tục. Nếu không, sau đó sửa đổi .gitattributesđể thể hiện tốt hơn những gì bạn muốn làm.

Người giới thiệu

1. Đặc tả GitHub LFS - Mô tả tuyệt vời về cách họ móc vào cleanvà smudgegọi hàm để thay thế tệp của bạn trong các gitđối tượng bằng tệp văn bản đơn giản bằng hàm băm.

2. Tài liệu gitattribut - Tất cả các chi tiết về những gì có sẵn để tùy chỉnh cách gitxử lý tài liệu của bạn.

Tôi đã từng gặp vấn đề tương tự. Tôi đã làm git reset --hard HEADnhưng vẫn mỗi lần tôi làm git statuslà tôi thấy một số tệp được sửa đổi.

Giải pháp của tôi tương đối đơn giản. Tôi vừa đóng IDE của mình (ở đây là Xcode) và đóng dòng lệnh của tôi (ở đây là terminal trên Mac OS của tôi) và thử lại và nó đã hoạt động.

Tuy nhiên, tôi không bao giờ có thể tìm thấy những gì bắt nguồn từ vấn đề.

Tôi tin rằng có một vấn đề với git cho Windows khi git viết ngẫu nhiên các kết thúc dòng sai khi thanh toán và cách giải quyết duy nhất là kiểm tra một số chi nhánh khác và buộc git bỏ qua các thay đổi. Sau đó kiểm tra chi nhánh bạn thực sự muốn làm việc.

git checkout master -f
git checkout <your branch>

Xin lưu ý rằng điều này sẽ loại bỏ bất kỳ thay đổi nào bạn có thể đã cố ý thực hiện, vì vậy chỉ thực hiện việc này nếu bạn gặp vấn đề này ngay sau khi thanh toán.

Chỉnh sửa: Tôi có thể đã thực sự gặp may mắn lần đầu tiên. Hóa ra tôi đã nhận được một lần nữa sau khi chuyển nhánh. Hóa ra các tệp git đã báo cáo là đã sửa đổi sau khi thay đổi các nhánh đang thay đổi. (Rõ ràng vì git không nhất quán áp dụng dòng CRLF kết thúc cho các tệp đúng cách.)

Tôi đã cập nhật lên git mới nhất cho Windows và hy vọng vấn đề không còn nữa.

Vấn đề tương tự, mặc dù tôi chỉ chắc chắn trên bề mặt. Dù sao, nó có thể giúp ai đó: những gì tôi đã làm (FWIW, trong SourceTree): đã lưu tệp không được cam kết, sau đó thực hiện thiết lập lại cứng.

Như các câu trả lời khác đã chỉ ra, vấn đề là do sửa lỗi tự động đầu dòng. Tôi gặp phải vấn đề này với các tệp * .svg. Tôi đã sử dụng tập tin svg cho các biểu tượng trong dự án của tôi.

Để giải quyết vấn đề này, tôi cho git biết rằng các tệp svg nên được coi là nhị phân thay vì văn bản bằng cách thêm dòng dưới đây vào .gitattribut

* .svg nhị phân

Trong một tình huống tương tự. Là kết quả của nhiều năm dằn vặt với nhiều lập trình viên, những người có thể nhét các bảng mã khác nhau vào cuối dòng (. Asp , .js, .css ... không phải là bản chất) vào một tệp. Một thời gian trước đã từ chối .gitattribut. Cài đặt cho repo trái autorclf = truevà safecrlf = warn.

Vấn đề cuối cùng nảy sinh khi đồng bộ hóa từ kho lưu trữ với các đầu dòng khác nhau. Sau khi sao chép từ kho lưu trữ, trong trạng thái git, nhiều tệp được thay đổi cùng với ghi chú

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

Mẹo từ Làm thế nào để bình thường hóa kết thúc dòng cây làm việc trong Git? đã giúp

git add -u

Một khả năng khác mà tôi gặp phải là một trong các gói trong kho lưu trữ kết thúc với một ĐẦU tách rời. Nếu không có câu trả lời nào ở đây có ích và bạn gặp phải một thông báo trạng thái git như thế này thì bạn có thể gặp vấn đề tương tự:

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)

Đi vào path/to/packagethư mục git statussẽ mang lại kết quả như sau:

HEAD detached at 7515f05

Và lệnh sau đây sẽ khắc phục sự cố, nơi mastercần được thay thế bởi chi nhánh địa phương của bạn:

git checkout master

Và bạn sẽ nhận được một thông báo rằng chi nhánh địa phương của bạn sẽ có một số lượng cam kết đằng sau chi nhánh từ xa. git pullvà bạn nên ra khỏi rừng!

Đối với một số lý do

git add .

không làm việc , nhưng

$ git add -A

làm việc ra