Tại sao tôi nên sử dụng core.autocrlf = true trong Git?

Tôi có kho lưu trữ Git được truy cập từ cả Windows và OS X và tôi biết rằng đã chứa một số tệp có kết thúc dòng CRLF. Theo như tôi có thể nói, có hai cách để giải quyết vấn đề này:

1. Đặt core.autocrlfđể falseở khắp mọi nơi,

2. Làm theo các hướng dẫn ở đây (được lặp lại trên các trang trợ giúp của GitHub) để chuyển đổi kho lưu trữ để chỉ chứa các kết thúc dòng của LF và sau đó được đặt core.autocrlfthành truetrên Windows và inputtrên OS X. Vấn đề với việc này là nếu tôi có bất kỳ tệp nhị phân nào trong kho lưu trữ cái đó:

   1. không được đánh dấu chính xác là nhị phân trong gitattribut và
   2. tình cờ có chứa cả CRLF và LF,

   họ sẽ bị hỏng Có thể kho lưu trữ của tôi chứa các tập tin như vậy.

Vậy tại sao tôi không nên tắt chuyển đổi kết thúc dòng của Git? Có rất nhiều cảnh báo mơ hồ trên web về việc core.autocrlfđã tắt gây ra sự cố, nhưng rất ít vấn đề cụ thể ; điều duy nhất tôi tìm thấy cho đến nay là kdiff3 không thể xử lý các kết thúc CRLF (không phải là vấn đề đối với tôi) và một số trình soạn thảo văn bản có vấn đề kết thúc dòng (cũng không phải là vấn đề đối với tôi).

Kho lưu trữ là nội bộ của công ty tôi và vì vậy tôi không cần phải lo lắng về việc chia sẻ nó với những người có cài đặt autocrlf khác nhau hoặc yêu cầu kết thúc dòng.

Có bất kỳ vấn đề nào khác khi chỉ để lại kết thúc dòng như là tôi không biết?

Những lý do cụ thể duy nhất để đặt autocrlfthành truelà:

• tránh git statushiển thị tất cả các tệp của bạn modifiedvì chuyển đổi EOL tự động được thực hiện khi sao chép repo EOL Git dựa trên Unix sang Windows ( ví dụ: xem vấn đề 83 )
• và các công cụ mã hóa của bạn bằng cách nào đó phụ thuộc vào kiểu EOL gốc có trong tệp của bạn:
  • ví dụ, một trình tạo mã được mã hóa cứng để phát hiện EOL gốc
  • các lô bên ngoài khác (bên ngoài repo của bạn) với regrec hoặc mã được đặt để phát hiện EOL gốc
  • Tôi tin rằng một số trình cắm Eclipse có thể tạo các tệp với CRLF bất kể trên nền tảng, đây có thể là một vấn đề.
  • Bạn mã bằng Notepad.exe ( trừ khi bạn đang sử dụng Windows 10 2018.09+, trong đó Notepad tôn trọng ký tự EOL được phát hiện ).

Trừ khi bạn có thể thấy điều trị đặc hiệu mà phải đối phó với EOL bản xứ, bạn là tốt hơn hết để lại autocrlfchofalse ( git config --global core.autocrlf false).

Lưu ý rằng cấu hình này sẽ là cấu hình cục bộ (vì cấu hình không được đẩy từ repo sang repo)

Nếu bạn muốn cấu hình giống nhau cho tất cả người dùng nhân bản repo đó, hãy xem " Chiến lược xử lý tốt nhất CRLFvới git là gì? ", Sử dụng textthuộc tính trong .gitattributestệp .

Thí dụ:

*.vcproj    text eol=crlf
*.sh        text eol=lf

Lưu ý: bắt đầu git 2.8 (tháng 3 năm 2016), các dấu hợp nhất sẽ không còn giới thiệu kết thúc dòng hỗn hợp (LF) trong tệp CRLF.
Xem " Tạo Git sử dụng CRLF trên dòng <<<<<<< ĐẦU TIẾT "

Tôi là một nhà phát triển .NET và đã sử dụng Git và Visual Studio trong nhiều năm. Khuyến nghị mạnh mẽ của tôi là đặt kết thúc dòng thành đúng. Và làm điều đó sớm nhất có thể trong vòng đời của Kho lưu trữ của bạn.

Điều đó đang được nói, tôi ghét rằng Git thay đổi kết thúc dòng của tôi. Kiểm soát nguồn chỉ nên lưu và truy xuất công việc tôi làm, KHÔNG nên sửa đổi nó. Không bao giờ. Nhưng nó làm.

Điều gì sẽ xảy ra nếu bạn không đặt mọi nhà phát triển thành đúng, cuối cùng thì MỘT nhà phát triển sẽ được đặt thành đúng. Điều này sẽ bắt đầu thay đổi kết thúc dòng của tất cả các tệp của bạn thành LF trong repo của bạn. Và khi người dùng đặt thành kiểm tra sai, Visual Studio sẽ cảnh báo bạn và yêu cầu bạn thay đổi chúng. Bạn sẽ có 2 điều xảy ra rất nhanh. Một, bạn sẽ nhận được càng nhiều những cảnh báo đó, nhóm của bạn càng lớn bạn càng nhận được nhiều. Điều thứ hai, và điều tồi tệ hơn là nó sẽ cho thấy rằng mọi dòng của mỗi tệp được sửa đổi đã bị thay đổi (bởi vì kết thúc dòng của mỗi dòng sẽ được thay đổi bởi người thực sự). Cuối cùng, bạn sẽ không thể theo dõi các thay đổi trong repo của mình một cách đáng tin cậy nữa. Thật dễ dàng và sạch sẽ hơn để làm cho mọi người giữ đúng, hơn là cố gắng giữ cho mọi người sai. Thật kinh khủng khi sống với thực tế là kiểm soát nguồn đáng tin cậy của bạn đang làm điều gì đó không nên. Không bao giờ.

Cập nhật 2 :

Xcode 9 dường như có một "tính năng" trong đó nó sẽ bỏ qua các kết thúc dòng hiện tại của tệp và thay vào đó chỉ sử dụng cài đặt kết thúc dòng mặc định của bạn khi chèn các dòng vào một tệp, dẫn đến các tệp có kết thúc dòng hỗn hợp.

Tôi khá chắc chắn rằng lỗi này không tồn tại trong Xcode 7; không chắc chắn về Xcode 8. Tin tốt là nó dường như được sửa trong Xcode 10.

Trong thời gian tồn tại, lỗi này đã gây ra một số ít sự vui nhộn trong cơ sở mã mà tôi đề cập đến trong câu hỏi (mà ngày nay sử dụng autocrlf=false), và dẫn đến nhiều thông điệp cam kết "EOL" và cuối cùng là tôi viết một git pre-commithook để kiểm tra cho / ngăn chặn giới thiệu kết thúc dòng hỗn hợp.

Cập nhật :

Lưu ý: Như VonC đã lưu ý, bắt đầu từ Git 2.8, các điểm đánh dấu hợp nhất sẽ không giới thiệu các kết thúc dòng kiểu Unix cho tệp kiểu Windows .

Bản gốc :

Một trục trặc nhỏ mà tôi nhận thấy với thiết lập này là khi có xung đột hợp nhất, các dòng git thêm vào để đánh dấu sự khác biệt không có kết thúc dòng Windows, ngay cả khi phần còn lại của tệp có và bạn có thể kết thúc với một tệp có kết thúc dòng hỗn hợp, ví dụ:

// Some code<CR><LF>
<<<<<<< Updated upstream<LF>
// Change A<CR><LF>
=======<LF>
// Change B<CR><LF>
>>>>>>> Stashed changes<LF>
// More code<CR><LF>

Điều này không gây ra cho chúng tôi bất kỳ vấn đề nào (tôi tưởng tượng bất kỳ công cụ nào có thể xử lý cả hai loại kết thúc dòng cũng sẽ xử lý hợp lý với các kết thúc dòng hỗn hợp - chắc chắn là tất cả những công cụ chúng tôi sử dụng), nhưng đó là điều cần chú ý.

Một điều khác ^* chúng tôi đã tìm thấy, là khi sử dụng git diffđể xem các thay đổi đối với tệp có kết thúc dòng Windows, các dòng đã được thêm sẽ hiển thị lợi nhuận vận chuyển của họ, do đó:

    // Not changed

+   // New line added in^M
+^M
    // Not changed
    // Not changed

_{* Nó không thực sự xứng đáng với thuật ngữ: "vấn đề".}