CRLF 끝 줄이있는 파일을 커밋하려고했지만 실패했습니다.

나는 하루 종일 Windows 컴퓨터에서 다른 전략을 시도했지만 Git 사용을 중단하고 대신 Mercurial 을 시도하려고 거의 매료되었습니다 .

답변 당 하나의 모범 사례 만 공유하십시오.

이 질문을한지 거의 4 년이지나 마침내 나는 완전히 나를 만족시키는 답을 찾았 습니다 !

줄 끝 처리 에 대한 github : help 's guide 의 세부 사항을 참조하십시오 .

힘내를 사용하면 파일 의 텍스트 속성 을 사용하여 리포지토리의 줄 끝 속성을 직접 설정할 수 있습니다 .gitattributes. 이 파일은 저장소에 커밋되어 core.autocrlf설정을 재정의 하므로 git 설정에 관계없이 모든 사용자에게 일관된 동작을 보장 할 수 있습니다.

따라서

이것의 장점은 이제 EOL (End of Line) 구성이 리포지토리와 함께 이동하므로 공동 작업자가 적절한 전역 설정을 가지고 있는지에 대해 걱정할 필요가 없다는 것입니다.

다음은 .gitattributes파일 의 예입니다

# Auto detect text files and perform LF normalization
*        text=auto

*.cs     text diff=csharp
*.java   text diff=java
*.html   text diff=html
*.css    text
*.js     text
*.sql    text

*.csproj text merge=union
*.sln    text merge=union eol=crlf

*.docx   diff=astextplain
*.DOCX   diff=astextplain

# absolute paths are ok, as are globs
/**/postinst* text eol=lf

# paths that don't start with / are treated relative to the .gitattributes folder
relative/path/*.txt text eol=lf

가장 널리 사용되는 프로그래밍 언어에 대해 .gitattributes 파일 을 바로 사용할 수 있는 편리한 모음이 있습니다. 시작하는 것이 좋습니다.

을 만들거나 조정했으면 .gitattributes한 번에 모든 줄 끝을 다시 정규화해야 합니다.

있습니다 GitHub의 데스크톱 응용 프로그램이 제안하고 만들 수 있습니다 .gitattributes앱에서 프로젝트의 힘내의 repo를 연 후 파일을. 이를 확인하려면 오른쪽 상단 모서리에있는 톱니 바퀴 아이콘> 리포지토리 설정 ...> 줄 끝 및 속성을 클릭하십시오. 권장 사항을 추가하라는 메시지가 표시되며 .gitattributes동의하면 리포지토리에있는 모든 파일의 정규화도 수행됩니다.

마지막으로, 마인드 엔드 오브 라인 (The Mind the End of Your Line) 기사는 더 많은 배경을 제공하고 Git이 현재 진행중인 문제를 어떻게 발전 시켰는지 설명합니다. 나는 이것이 필요한 독서를 고려한다 .

팀에 EGit 또는 JGit (Eclipse 및 TeamCity와 같은 도구)를 사용하여 변경 사항을 커밋 한 사용자가있을 수 있습니다. @gatinueta 가이 답변의 의견에서 설명했듯이 운이 좋지 않습니다.

이 도구는 팀에서 Egit 또는 JGit을 사용하는 사람들이 있으면 .gitattributes를 무시하고 CRLF 파일을 행복하게 확인하므로 https://bugs.eclipse.org/bugs/show_bug.cgi? id = 342372

한 가지 트릭은 다른 클라이언트에서 변경 사항을 커밋하는 것입니다 ( SourceTree) . 당시 우리 팀은 많은 사용 사례에서이 도구를 Eclipse의 EGit보다 선호했습니다.

누가 소프트웨어가 쉽다고 말했습니까? :-/

줄 끝을 변환하지 마십시오. 데이터를 해석하는 것은 VCS의 일이 아닙니다. 단지 데이터를 저장하고 버전을 지정하기 만하면됩니다. 현대의 모든 텍스트 편집기는 어쨌든 두 종류의 줄 끝을 읽을 수 있습니다.

당신 autocrlf=input이하고있는 일을 정말로 모른다면 거의 항상 원합니다 .

아래에 몇 가지 추가 컨텍스트가 있습니다.

core.autocrlf=trueDOS 종료 core.autocrlf=input를 좋아 하거나 unix-newlines를 선호하는 경우 여야합니다 . 두 경우 모두 Git 리포지토리에는 LF 만 있습니다. 에 대한 유일한 주장 core.autocrlf=false은 자동 휴리스틱이 일부 바이너리를 텍스트로 잘못 감지하여 타일이 손상 될 수 있다는 것입니다. 따라서 core.safecrlf돌이킬 수없는 변경이 발생하면 사용자에게 경고하는 옵션이 도입되었습니다. 실제로, 돌이킬 수없는 변경의 두 가지 가능성이 있습니다-텍스트 파일의 혼합 줄 끝.이 정규화가 바람직 하므로이 경고를 무시하거나 Git이 바이너리 파일을 텍스트로 잘못 감지했을 가능성이 큽니다. 그런 다음 속성을 사용하여 Git에게이 파일이 이진 파일임을 알려야합니다.

위의 단락은 원래 gmane.org의 스레드에서 가져 왔지만 이후 중단되었습니다.

혼합 환경 (Microsoft + Linux + Mac)에서 라인 엔딩을 일관성있게 유지 하기 위한 두 가지 대체 전략 :

A. 모든 리포지토리 당 전역 설정

1) 모두를 하나의 형식으로 변환

find . -type f -not -path "./.git/*" -exec dos2unix {} \;
git commit -a -m 'dos2unix conversion'

2) 설정 core.autocrlf에 input리눅스 / UNIX 나 true) MS Windows에서 (저장소 또는 글로벌

git config --global core.autocrlf input

3) [선택 사항] core.safecrlf을 true(정지) 또는 warn(노래 :)로 설정하여 역행 된 줄 바꾸기 변환으로 인해 동일한 파일이 생성 될 경우 추가 가드를 추가합니다.

git config --global core.safecrlf true

B. 또는 리포지토리 설정

1) 모두를 하나의 형식으로 변환

find . -type f -not -path "./.git/*" -exec dos2unix {} \;
git commit -a -m 'dos2unix conversion'

2) .gitattributes저장소 에 파일 추가

echo "* text=auto" > .gitattributes
git add .gitattributes
git commit -m 'adding .gitattributes for unified line-ending'

바이너리 파일에 대해 걱정하지 마십시오. Git은 충분히 똑똑해야합니다.

safecrlf / autocrlf 변수에 대한 추가 정보

core.autocrlf구성 옵션을로 설정하십시오 true. 또한 core.safecrlf옵션을 살펴보십시오 .

실제로 다음과 같은 core.safecrlf이유로 저장소에 이미 설정된 것처럼 들립니다 .

이것이 core.autocrlf의 현재 설정이 아닌 경우 git은 파일을 거부합니다 .

이 경우 텍스트 편집기가 줄 끝을 일관되게 사용하도록 구성되어 있는지 확인할 수 있습니다. 텍스트 파일에 LF와 CRLF 줄 끝이 혼합되어 있으면 문제가 발생할 수 있습니다.

마지막으로, 나는 단순히 "주어진 것을 사용하고"Windows에서 LF로 끝나는 줄을 사용하는 것이 해결하는 것보다 더 많은 문제를 일으킬 것이라고 생각합니다. 힘내는 위의 옵션을 사용하여 현명한 방식으로 줄 끝을 처리하려고하므로 사용하는 것이 좋습니다.

Visual Studio 2010core.autocrlf=false 에서 파일을 체크 아웃하자마자 사용하여 모든 파일이 업데이트 된 것으로 표시되지 않도록 중지 프로젝트 . 개발 팀의 다른 두 구성원도 Windows 시스템을 사용하므로 혼합 환경이 작동하지 않지만 저장소와 함께 제공된 기본 설정은 항상 복제 직후 모든 파일이 업데이트 된 것으로 표시되었습니다.

결론은 환경에 어떤 CRLF 설정이 작동하는지 찾는 것입니다. 특히 Linux 박스 설정의 다른 많은 저장소에서 autocrlf = true더 나은 결과를 얻을 수 있기 때문입니다.

20 년이 지난 후에도 우리는 여전히 OS 간의 줄 끝 차이를 처리하고 있습니다.

Mac 또는 Linux 사용자 와 코드를 공유하는 Windows 및 Visual Studio 사용자를 위한 두 가지 옵션이 있습니다 . 자세한 설명은 gitattributes manual을 읽으십시오 .

* 텍스트 = 자동

레포 .gitattributes파일에 다음을 추가하십시오.

*   text=auto

이것은 LFrepo에서 줄 끝으로 모든 파일을 정규화합니다 .

또한 운영 체제 ( core.eol설정)에 따라 작업 트리의 파일이 LFUnix 기반 시스템 또는 CRLFWindows 시스템 에 맞게 정규화됩니다 .

이것은 Microsoft .NET repos가 사용 하는 구성입니다 .

예:

Hello\r\nWorld

항상 repo에서 다음과 같이 정규화됩니다.

Hello\nWorld

체크 아웃시 Windows의 작업 트리가 다음으로 변환됩니다.

Hello\r\nWorld

결제시 Mac의 작업 트리는 다음과 같이 남습니다.

Hello\nWorld

참고 : 리포지토리에 이미 정규화되지 않은 파일이 포함되어 있으면 git status다음에 파일을 변경할 때 이러한 파일이 완전히 수정 된 것으로 표시되므로 나중에 다른 사용자가 변경 내용을 병합하기가 어려울 수 있습니다. 자세한 내용은 줄 끝 을 변경 한 후 리포지토리 새로 고침 을 참조하십시오.

core.autocrlf = true

파일 text에서 지정되지 않은 경우 .gitattributesGit은 core.autocrlf구성 변수를 사용하여 파일을 변환해야하는지 여부를 결정합니다.

Windows 사용자의 경우 다음 git config --global core.autocrlf true과 같은 이유로 훌륭한 옵션입니다.

• 파일은 리포지토리에 추가 될 때만LF 줄 끝 으로 정규화됩니다 . 저장소에서 정규화되지 않은 파일이 있으면이 설정은 해당 파일을 건드리지 않습니다.
• 모든 텍스트 파일은 CRLF작업 디렉토리에서 줄 끝으로 변환됩니다 .

이 접근법의 문제점은 다음과 같습니다.

• 을 사용하는 Windows 사용자 인 경우 줄 끝이 autocrlf = input있는 많은 파일이 LF표시됩니다. 커밋은 여전히 LF라인 엔딩 으로 정규화되므로 나머지 팀에게는 위험하지 않습니다 .
• 을 사용하는 Windows 사용자 인 경우 줄 끝이 core.autocrlf = false있는 많은 파일이 LF표시되고 CRLF줄 끝이있는 파일을 저장소에 소개 할 ​​수 있습니다 .
• 대부분의 Mac 사용자 autocrlf = input는 파일 확장자가있는 파일을 사용 하고 파일 확장자를 가진 CRLF파일을 얻을 수 있습니다 core.autocrlf = false.

--- 업데이트 3 --- (업데이트 2와 충돌하지 않음)

Windows 사용자는 텍스트 CRLF작업을 선호하고 linux / mac 사용자는 LF텍스트 파일 작업을 선호 합니다. 저장소 관리자 의 관점 에서 답변을 제공하십시오 .

나에게 가장 좋은 전략 (해결해야 할 문제가 적음)은 Windows 전용 프로젝트에서 작업하는 경우에도 모든 텍스트 파일 을 LFgit repo 안에 유지 하는 것입니다. 그런 다음 클라이언트 가 커밋을 위해 파일을 준비하는 동안 전략 을 존중할 속성 값 (리 포지션의 LF) 을 선택하는 경우 고객이 선호 하는 줄 끝 스타일을 자유롭게 사용할 수 있습니다 .core.autocrlf

준비 는 줄 바꾸기 전략의 작동 방식 을 이해 하려고 할 때 많은 사람들이 혼동 하는 것입니다. 올바른 속성 값을 선택하기 전에 다음 사항을 이해해야합니다 .core.autocrlf

• 커밋 할 텍스트 파일을 추가 ( 스테이징 ) 하는 것은 파일을 클라이언트 .git/디렉토리의 값에 따라 변환 된 줄 끝으로 하위 디렉토리 내의 다른 위치에 복사하는 것과 같습니다core.autocrlf . 이 모든 것은 로컬에서 수행 됩니다.
• 설정 core.autocrlf은 질문에 대한 답변을 제공하는 것과 같습니다 (모든 OS에서 동일한 질문).
  • "해야 자식 클라이언트 가. 변환 LF - 투 - CRLF 때 체크 아웃 원격에서 환매 특약 변경 (당기) 또는 나. 커밋에 대한 파일을 추가 할 때? 변환 CRLF - 투 - LF를 "및 가능한 대답 (값) 아르:
  • false:" 할 수없는 것도 위의를 "
  • input:" 않습니다 만 ㄱ "
  • true" 할 을하고와 b "
  • NO이 있음을 참고 " 만 할 "

다행히도

• git client defaults (windows : core.autocrlf: true, linux / mac :) core.autocrlf: false는 LF-only-repo 전략 과 호환됩니다 .
  의미 : Windows 클라이언트는 기본적으로 저장소를 체크 아웃 할 때 CRLF로 변환하고 커밋을 추가 할 때 LF로 변환합니다. 그리고 리눅스 클라이언트는 기본적으로 어떤 변환도하지 않습니다. 이것은 이론적으로 당신의 저장소를 유지합니다.

운수 나쁘게:

• 자식 core.autocrlf값을 존중하지 않는 GUI 클라이언트가있을 수 있습니다.
• lf-repo 전략을 존중하기 위해 가치를 사용하지 않는 사람들이있을 수 있습니다. 예를 들어 core.autocrlf=false커밋을 위해 CRLF 파일 을 사용 하고 추가합니다.

위의 클라이언트가 커밋 한 ASAP 비 lf 텍스트 파일을 감지하려면 --- update 2 --- : ( git grep -I --files-with-matches --perl-regexp '\r' HEAD, --with-libpcre플래그를 사용하여 컴파일 된 클라이언트에서 설명 된 내용을 따를 수 있습니다 .

그리고 여기에 캐치가 있습니다 : . 나는 repo 유지 관리자로서 git.autocrlf=input커밋을 위해 다시 추가하여 잘못 커밋 된 파일을 수정할 수 있도록 유지합니다 . 그리고 커밋 텍스트를 제공합니다 : "잘못된 커밋 파일 수정".

지금까지와 같은 .gitattributesconcearned된다. 나는 그것을 이해하지 못하는 더 많은 UI 클라이언트가 있기 때문에 그것에 의지하지 않습니다. 나는 텍스트와 이진 파일에 대한 힌트를 제공하고 어디에서나 동일한 줄 끝을 유지 해야하는 예외적 인 파일을 표시하는 데에만 사용합니다.

*.java          text !eol # Don't do auto-detection. Treat as text (don't set any eol rule. use client's)
*.jpg           -text     # Don't do auto-detection. Treat as binary
*.sh            text eol=lf # Don't do auto-detection. Treat as text. Checkout and add with eol=lf
*.bat           text eol=crlf # Treat as text. Checkout and add with eol=crlf

질문 : 그러나 왜 우리는 개행 처리 전략에 관심이 있습니까?

답변 : 단일 문자 변경 커밋 을 피하려면 변경 을 수행 한 클라이언트가 커밋을 위해 파일을 추가하기 전에 전체 파일을 crlf에서 lf (또는 그 반대로)로 자동 변환했기 때문에 5000 행 변경으로 나타납니다 . 갈등 해소 가있을 때 다소 고통 스러울 수 있습니다 . 또는 경우에 따라 불합리한 충돌의 원인이 될 수도 있습니다.

--- 업데이트 2 ---

git client의 dafault는 대부분의 경우 작동합니다. Windows 전용 클라이언트, Linux 전용 클라이언트 또는 둘 다가있는 경우에도 마찬가지입니다. 이것들은:

• windows : core.autocrlf=true 체크 아웃시 줄을 CRLF로 변환하고 파일을 추가 할 때 줄을 LF로 변환합니다.
• linux : core.autocrlf=input 파일을 추가 할 때 체크 아웃시 줄을 변환하지 않고 (파일을 LF로 커밋해야하기 때문에 필요하지 않음) 줄을 LF (필요한 경우)로 변환합니다. ( -update3- : 이것은 false기본적으로 보이지만 다시는 괜찮습니다)

이 속성은 다른 범위에서 설정할 수 있습니다. --global끝에 설명 된 일부 IDE 문제를 피하기 위해 범위 에서 명시 적으로 설정하는 것이 좋습니다 .

git config core.autocrlf
git config --global core.autocrlf
git config --system core.autocrlf
git config --local core.autocrlf
git config --show-origin core.autocrlf

또한 git documentation 제안 된 것과 달리 Windows (클라이언트 전용 창을 사용 하는 경우)에서는 사용 하지 않는 것이 좋습니다 . false로 설정하면 리포지토리에 CRLF가있는 파일이 커밋됩니다. 그러나 실제로 이유가 없습니다. Linux 사용자와 프로젝트를 공유해야하는지 여부를 절대 알 수 없습니다. 또한 기본값을 사용하는 대신 프로젝트에 참여하는 각 클라이언트에 대해 하나의 추가 단계입니다. git config --global core.autocrlf false

이제 *.bat *.shLF 또는 CRLF로 체크 아웃하려는 파일의 특별한 경우 (예 :)를 사용할 수 있습니다.gitattributes

요약 업하려면 나를 위해 가장 좋은 방법은 있습니다 :

• 이진 파일이 아닌 모든 파일이 git repo에서 LF로 커밋되었는지 확인하십시오 (기본 동작).
• : 어떤 파일이 CRLF로 최선을 다하고되지 않습니다 있는지 확인하려면이 명령을 사용합니다 git grep -I --files-with-matches --perl-regexp '\r' HEAD( 참고 : Windows 클라이언트에서만 통해 작동 git-bash하여 컴파일하는 경우에만 및 리눅스 클라이언트에서 --with-libpcre에서 ./configure).
• 위 명령을 실행하여 이러한 파일을 찾으면 정정하십시오. 이것은 적어도 리눅스에서는 관련이 있습니다.
  • 세트 core.autocrlf=input( --- 업데이트 3- )
  • 파일을 바꾸다
  • 변경 사항 되돌리기 (파일이 여전히 변경된 것으로 표시됨)
  • 커밋
• 최소값 만 사용하십시오 .gitattributes
• 사용자에게 core.autocrlf위에서 설명한 기본값 을 설정하도록 지시하십시오 .
• 의 존재에 100 %를 세지 마십시오 .gitattributes. IDE의 git-clients는 IDE를 무시하거나 다르게 취급 할 수 있습니다.

언급했듯이 git 속성에 몇 가지 사항을 추가 할 수 있습니다.

# Always checkout with LF
*.sh            text eol=lf
# Always checkout with CRLF
*.bat           text eol=crlf

.gitattributes이진 파일에 자동 감지를 사용 하는 대신 다른 안전한 옵션이 있다고 생각 합니다.

• -text(예 : 파일 *.zip또는 *.jpg파일 : 텍스트로 처리되지 않습니다. 따라서 줄 끝 변환은 시도되지 않습니다. 변환 프로그램을 통해 차이가 발생할 수 있습니다)
• text !eol(예 : *.java, *.html: 텍스트로 취급되지만 eol 스타일 환경 설정이 설정되어 있지 않으므로 클라이언트 설정이 사용됩니다.)
• -text -diff -merge(예 *.hugefile: 텍스트로 취급되지 않습니다. diff / merge 가능)

--- 이전 업데이트 ---

파일을 잘못 커밋하는 클라이언트의 한 가지 예 :

netbeans 8.2 (Windows) 는 명시 적 으로 global로 설정 하지 않으면 CRLF가있는 모든 텍스트 파일을 잘못 커밋합니다 . 이것은 표준 자식 클라이언트 동작과 모순되며 업데이트 / 병합하는 동안 나중에 많은 문제를 일으 킵니다. 이렇게 하면 되돌릴 때에도 일부 파일이 다르게 표시됩니다 (그렇지는 않지만) . 프로젝트 에 올바로 추가 한 경우에도 netbeans에서 동일한 동작이 발생 합니다.core.autocrlf
.gitattributes

커밋 후에 다음 명령을 사용하면 적어도 git repo에 줄 끝 문제가 있는지 여부를 조기에 감지하는 데 도움이됩니다. git grep -I --files-with-matches --perl-regexp '\r' HEAD

나는 가능한 한 최선의 사용법을 생각해 내고 .gitattributes마침내 그것을 믿을 수 없다는 것을 깨닫기 위해 몇 시간을 보냈습니다 .
안타깝게도 JGit 기반 편집기가 존재하는 한 ( .gitattributes올바로 처리 할 수없는 ) 안전한 솔루션은 편집기 수준에서도 LF를 강제로 사용하는 것입니다.

다음 anti-CRLF소독제를 사용하십시오 .

• 윈도우 / 리눅스 클라이언트 : core.autocrlf=input

• 커밋 .gitattributes: * text=auto eol=lf

• 커밋 된 .editorconfig( http://editorconfig.org/ ) 일종의 표준화 된 형식이며 편집기 플러그인과 결합됩니다.

  • https://github.com/editorconfig/
  • https://github.com/welovecoding/editorconfig-netbeans/

이것은 해결 방법 일뿐입니다 .

일반적인 경우에는 git과 함께 제공된 솔루션을 사용하십시오. 이들은 대부분의 경우에 효과적입니다. .gitattributes 를 설정하여 Windows 및 Unix 기반 시스템에서 개발을 공유하는 경우 LF로 강제 실행하십시오 .

필자의 경우 Windows에서 프로젝트를 개발하는 프로그래머가 10 명 이상이었습니다. 이 프로젝트는 CRLF로 체크인되었으며 LF에 강제로 참여할 수있는 옵션이 없습니다.

일부 설정은 LF 형식에 영향을주지 않고 내 컴퓨터에 내부적으로 기록되었습니다. 따라서 일부 작은 파일을 변경할 때마다 일부 파일이 전체적으로 LF로 변경되었습니다.

내 해결책 :

Windows- 기계 : 모든 것을 그대로 둡니다. 기본 윈도우 'lone wolf'개발자이기 때문에 아무것도 걱정하지 마십시오. "전 세계에는 다른 시스템이 없습니까?"

유닉스 기계

1. 구성 [alias]섹션에 다음 행을 추가 하십시오. 이 명령은 모든 변경된 (즉, 수정 된 / 새로운) 파일을 나열합니다.

   lc = "!f() { git status --porcelain \
                | egrep -r \"^(\?| ).\*\\(.[a-zA-Z])*\" \
                | cut -c 4- ; }; f "

2. 변경된 모든 파일을 dos 형식으로 변환하십시오 .

   unix2dos $(git lc)

3. 선택적으로 ...

   1. 이 프로세스를 자동화하기 위해이 조치에 대한 git hook 을 작성하십시오.

   2. params를 사용하고 포함하고 grep특정 파일 이름과 일치 하도록 함수를 수정하십시오 .

      ... | egrep -r "^(\?| ).*\.(txt|conf)" | ...

   3. 추가 단축키를 사용하여 더 편리하게 만드십시오.

      c2dos = "!f() { unix2dos $(git lc) ; }; f "

      ...를 입력하여 변환 된 물건을 발사하십시오.

      git c2dos