LF를 CRLF로 대체하는 git

bash를 사용하여 Windows XP 시스템에서 git 실행 SVN에서 프로젝트를 내 보낸 다음 베어 리포지토리를 복제했습니다.

그런 다음 내보내기를 베어 리포지토리 디렉토리에 붙여 넣고 다음을 수행했습니다.

git add -A

그런 다음 메시지 목록을 얻었습니다.

LF는 CRLF로 대체됩니다

이 전환의 결과는 무엇입니까? 이것은 Visual Studio의 .NET 솔루션입니다.

이 메시지는 core.autocrlfWindows의 기본값이 올바르지 않기 때문 입니다.

개념은 autocrlf줄 끝 변환을 투명하게 처리하는 것입니다. 그리고 그렇습니다!

나쁜 소식 : 값을 수동으로 구성해야합니다.
좋은 소식 : git 설치 당 한 번만 수행해야합니다 (프로젝트 당 설정 가능).

어떻게 autocrlf작동 :

core.autocrlf=true:      core.autocrlf=input:     core.autocrlf=false:

        repo                     repo                     repo
      ^      V                 ^      V                 ^      V
     /        \               /        \               /        \
crlf->lf    lf->crlf     crlf->lf       \             /          \      
   /            \           /            \           /            \

여기 crlf= 윈 스타일 줄 끝 마커,lf = 유닉스 스타일 (및 맥 OSX).

(사전 OSX cr 위의 세 가지 옵션 중 하나에 영향을 미치지 않는 )

이 경고는 언제 표시됩니까 (Windows에서)

    - autocrlf= true당신이 유닉스 스타일이있는 경우 lf파일 중 하나 (= 드물게),
    - autocrlf= input당신이 이길 스타일이있는 경우 crlf파일 중 하나 (= 거의 항상),
    - autocrlf= false- NEVER!

이 경고는 무엇을 의미합니까

"경고 LF를 CRLF로 대체 될 것이다 "당신이 (갖는 말한다autocrlftrue 커밋 체크 아웃주기 후 =를 ) 유닉스 스타일의 LF를 잃게 Windows 스타일의 CRLF로 대체 됨). Git은 윈도우에서 유닉스 스타일의 LF를 사용할 것을 기대하지 않습니다.

경고 " CRLF를 LF로 대체 될 것이다 "당신은 (가지고 있다고 autocrlf= inputA는 (은 유닉스 스타일의 LF로 대체됩니다) 사이클 체크 아웃 커밋 후 창 스타일 CRLF을 잃게됩니다). 사용하지 마십시오input창문 아래에서 .

autocrlf작동 방식을 보여주는 또 다른 방법

1) true:             x -> LF -> CRLF
2) input:            x -> LF -> LF
3) false:            x -> x -> x

여기서 x 는 CRLF (Windows 스타일) 또는 LF (unix 스타일)이며 화살표는

file to commit -> repository -> checked out file

어떻게 고치는 지

에 대한 기본값 core.autocrlf은 git 설치 중에 선택되어 시스템 전체 gitconfig (%ProgramFiles(x86)%\git\etc\gitconfig )에 . 또한 다음 순서로 계단식으로 표시됩니다.

   – "글로벌"(사용자 별) gitconfig는에 위치하고 ~/.gitconfig또 다른
   – "글로벌"(사용자 별) gitconfig는 $XDG_CONFIG_HOME/git/config또는 $HOME/.config/git/config및
   "로컬"(사용자 당) gitconfig는.git/config 는 작업 디렉토리에 있습니다.

그래서 쓰기 git config core.autocrlf 현재 사용중인 값을 확인하기 위해 작업 디렉토리에 작성하십시오.

   – autocrlf=false시스템 전체 gitconfig에 추가 # 시스템 별 솔루션
   – git config --global core.autocrlf false            # 사용자 별 솔루션
   –git config --local core.autocrlf false              # 프로젝트 별 솔루션

경고
– git config설정으로 설정을 무시할 수 있습니다 gitattributes.
– crlf -> lf새 파일을 추가 할 때만 변환됩니다.crlf , 저장소에 이미 존재하는 파일은 영향을받지 않습니다.

도덕 (Windows 용) :
    - 사용 core.autocrlf= true당신이 (당신의 편집기 / IDE가 유닉스 라인 엔딩을 사용하도록 구성하고 내키지)뿐만 아니라 유닉스에서이 프로젝트를 사용하려는 경우
    사용 - core.autocrlf= false당신이 Windows에서 만 (이 프로젝트를 사용하려는 경우 또는 당신은 당신의 편집기를 구성 / IDE는) 유닉스 라인 엔딩을 사용하는
    - 결코 사용하지 core.autocrlf= input당신이 (에 좋은 이유가없는 한 예를 당신이 윈도우에서 유닉스 유틸리티를 사용하는 경우 또는 당신이) 메이크 문제로 실행하면,

추신 : Windows 용 git을 설치할 때 선택해야 할 것은 무엇입니까?
Unix에서 프로젝트를 사용 하지 않으 려면 기본 첫 번째 옵션에 동의 하지 마십시오 . 세 번째 것을 선택하십시오 (있는 그대로 체크 아웃, 그대로 커밋 ). 이 메시지가 표시되지 않습니다. 이제까지.

PPS 개인적으로 선호하는 것은 Unix 스타일의 엔딩을 사용 하도록 에디터 / IDE 를 설정하고로 설정 core.autocrlf하는 것 false입니다.

힘내는 줄 끝을 처리하는 세 가지 모드가 있습니다.

$ git config core.autocrlf
# that command will print "true" or "false" or "input"

true또는 의 추가 매개 변수를 추가하여 사용할 모드를 설정할 수 있습니다false 위의 명령 라인에.

core.autocrlftrue로 설정 되면 , git가 생각하는 git repo에 파일을 텍스트 파일로 추가 할 때마다 모든 CRLF 줄 끝이 커밋에 저장되기 전에 LF로 바뀝니다. 언제든지 너를git checkout 무언가를 , 모든 텍스트 파일은 자동으로 LF 줄 끝을 CRLF 끝으로 변환합니다. 따라서 줄 끝 스타일이 항상 일관되게 LF이므로 각 편집기가 줄 끝 스타일을 변경하기 때문에 커밋이 커지지 않고 다른 줄 끝 스타일을 사용하는 플랫폼에서 프로젝트를 개발할 수 있습니다.

이 편리한 변환의 부작용, 그리고 이것이 당신이보고있는 경고에 대한 것입니다, 당신이 만든 텍스트 파일이 원래 CRLF 대신에 LF 엔딩을 가지고 있다면, 평소와 같이 LF와 함께 저장되지만, 체크 될 때 나중에 CRLF 엔딩이 생깁니다. 일반 텍스트 파일의 경우 일반적으로 좋습니다. 이 경우 경고는 "정보 용"이지만 git이 이진 파일을 텍스트 파일로 잘못 평가하는 경우 git이 이진 파일을 손상시킬 수 있으므로 중요한 경고입니다.

경우 core.autocrlffalse로 설정되어있는 텍스트 파일이-그대로 체크되도록, 더 라인 끝 변환은 이제까지 수행되지 않습니다. 모든 개발자가 Linux 또는 Windows에있는 한 일반적으로 정상적으로 작동합니다. 그러나 내 경험에 따르면 여전히 줄 끝이 혼합 된 텍스트 파일이 문제를 일으키는 경향이 있습니다.

개인적으로 선호하는 것은 Windows 개발자로서 설정을 ON으로 유지하는 것입니다.

"입력"값을 포함하는 업데이트 된 정보는 http://kernel.org/pub/software/scm/git/docs/git-config.html 을 참조하십시오 .

이미 코드를 체크 아웃 한 경우 파일이 이미 색인화되었습니다. 자식 설정을 변경 한 후 다음을 실행하십시오.

git config --global core.autocrlf input 

당신은 색인을 새로 고쳐야한다

git rm --cached -r . 

git index를 사용하여 다시 작성하십시오.

git reset --hard

https://help.github.com/articles/dealing-with-line-endings/#refreshing-a-repository-after-changing-line-endings

참고 : 로컬 변경 사항이 제거되므로이를 수행하기 전에이를 변경하십시오.

git config core.autocrlf false

두 unix2dos를 하고 DOS2UNIX은 gitbash와 윈도우에서 사용할 수 있습니다. 다음 명령을 사용하여 UNIX (LF)-> DOS (CRLF) 변환을 수행 할 수 있습니다. 따라서 경고가 표시되지 않습니다.

unix2dos filename

또는

dos2unix -D filename

그러나 기존 CRLF 파일에서이 명령을 실행하지 않으면 두 번째 줄마다 빈 줄 바꿈이 표시됩니다.

dos2unix -D filename모든 운영 체제에서 작동하지는 않습니다. 이 링크를 확인 하십시오호환성에 대해서는 를 .

어떤 이유로 명령을 강제 실행해야하는 경우을 사용하십시오 --force. 유효하지 않다면를 사용하십시오 -f.

@Basiloungas의 대답 은 가깝지만 오래되었습니다 (적어도 Mac에서는).

~ / .gitconfig 파일을 열고 safecrlffalse로 설정하십시오.

[core]
       autocrlf = input
       safecrlf = false

그것은 줄 char의 끝을 분명히 무시하게 할 것입니다 (어쨌든 나를 위해 일했습니다).

이 주제에 대해 이야기 할 때 줄 끝에 관한 GitHub의 기사 가 일반적으로 언급됩니다.

자주 권장되는 core.autocrlf구성 설정 사용에 대한 개인적인 경험 은 매우 혼합되었습니다.

Cygwin과 함께 Windows를 사용하고 있으며 다른 시간에 Windows와 UNIX 프로젝트를 모두 처리합니다. 내 Windows 프로젝트조차도 때때로 bash쉘 스크립트를 사용하는데 , 이는 UNIX (LF) 줄 끝이 필요합니다.

GitHub 사용 권장 core.autocrlfCygwin에서 완벽하게 작동하는 UNIX 프로젝트를 확인하거나 Linux 서버에서 사용하는 프로젝트에 기여하는 경우 Windows 설정을 사용하여 텍스트 파일은 Windows (CRLF)에서 체크 아웃됩니다 ) 줄 끝으로 인해 문제가 발생합니다.

기본적으로 내가 가진 혼합 환경의 경우 전역 core.autocrlf을 옵션 중 하나로 설정하면 경우에 따라 작동하지 않습니다. 이 옵션은 로컬 (리포지토리) git 구성에서 설정할 수 있지만 Windows 및 UNIX 관련 항목이 모두 포함 된 프로젝트에는 충분하지 않습니다 (예 : 일부 bash유틸리티 스크립트 가있는 Windows 프로젝트가 있음 ).

내가 찾은 최선의 선택은 저장소마다 .gitattributes 파일 을 만드는 것입니다 . GitHub의 기사 를 언급하고있다.
그 기사의 예 :

# Set the default behavior, in case people don't have core.autocrlf set.
* text=auto

# Explicitly declare text files you want to always be normalized and converted
# to native line endings on checkout.
*.c text
*.h text

# Declare files that will always have CRLF line endings on checkout.
*.sln text eol=crlf

# Denote all files that are truly binary and should not be modified.
*.png binary
*.jpg binary

내 프로젝트의 저장소 중 하나에서

* text=auto

*.txt         text eol=lf
*.xml         text eol=lf
*.json        text eol=lf
*.properties  text eol=lf
*.conf        text eol=lf

*.awk  text eol=lf
*.sed  text eol=lf
*.sh   text eol=lf

*.png  binary
*.jpg  binary

*.p12  binary

설정해야 할 것이 더 많지만 프로젝트 당 한 번만 수행하면 모든 OS의 기여자는이 프로젝트로 작업 할 때 줄 끝에 문제가 없어야합니다.

: VIM에서 (예를 들어, 파일을 열고 :e YOURFILEENTER, 다음)

:set noendofline binary
:wq

나도이 문제가 있었다.

SVN은 줄 끝 변환을 수행하지 않으므로 파일은 CRLF 줄 끝을 그대로 유지합니다. 그런 다음 git-svn을 사용하여 프로젝트를 git에 넣으면 CRLF 엔딩이 git 리포지토리에 유지됩니다 .git 저장소는 git이 자신을 찾을 것으로 예상되는 상태가 아닙니다. 기본적으로 유닉스 / 리눅스 (LF) 줄 엔딩 만 있어야합니다 체크인했습니다.

그런 다음 Windows에서 파일을 체크 아웃하면 autocrlf 변환은 파일을 그대로 유지합니다 (이미 현재 플랫폼에 대한 올바른 끝이 있기 때문에) 체크인 된 파일과의 차이가 있는지 여부를 결정하는 프로세스는 역 변환을 수행합니다. 비교 하기 전에 체크 아웃 된 파일의 LF라고 ​​생각되는 것을 저장소의 예기치 않은 CRLF와 비교합니다.

내가 볼 수있는 한 당신의 선택은 :

1. git-svn을 사용하지 않고 코드를 새로운 git 저장소로 다시 가져옵니다. 즉, 줄 끝은 초기 git commit 에서 변환됩니다.
2. autocrlf를 false로 설정하고 줄 끝이 git이 선호하는 스타일이 아니라는 사실을 무시하십시오.
3. autocrlf를 끈 상태에서 파일을 확인하고 모든 줄 끝을 수정하고 모든 항목을 다시 확인한 후 다시 켜십시오.
4. 원래 커밋에 더 이상 자식이 예상하지 못한 CRLF를 포함하지 않도록 저장소의 기록을 다시 작성하십시오. (역사 재 작성에 대한 일반적인 경고가 적용됨)

각주 : 옵션 # 2를 선택하면 내 경험에 따라 일부 보조 도구 (리베이스, 패치 등)가 CRLF 파일에 대처하지 못하고 CRLF와 LF가 혼합 된 파일로 조만간 끝날 것입니다 (일관되지 않은 줄) 결말). 나는 두 가지 모두를 최대한 활용하는 방법을 모른다.

~ / .gitattributes 파일에서 아래를 제거

* text=auto

처음에는 git이 줄 끝을 확인하지 못하게합니다.

읽어야합니다.

경고 : ( 현재 core.autocrlf가있는 다른 폴더로 체크 아웃하거나 복제하면true LF가 CRLF로 바뀝니다.

파일은 ( 현재 ) 작업 디렉토리 에 원래 줄 끝이 있습니다 .

이 그림은 그 의미를 설명해야합니다.

http://www.rtuin.nl/2013/02/how-to-make-git-ignore-different-line-endings/

echo "* -crlf" > .gitattributes 

별도의 커밋 에서이 작업을 수행하거나 단일 변경을 수행 할 때 git에서 여전히 전체 파일이 수정 된 것으로 볼 수 있습니다 (autocrlf 옵션을 변경 한 경우에 따라 다름)

이것은 실제로 작동합니다. Git은 혼합 라인 엔딩 프로젝트에서 라인 엔딩을 존중하고 경고하지 않습니다.

Windows의 git에 대해 많이 모르지만 ...

git이 실행중인 플랫폼 (Windows)의 반환 형식과 일치하도록 반환 형식을 변환하고 있다고 나타납니다. CRLF는 Windows의 기본 반환 형식이며 LF는 대부분의 다른 OS의 기본 반환 형식입니다.

코드가 다른 시스템으로 이동 될 때 리턴 형식이 올바르게 조정될 수 있습니다. 또한 git은 JPEG와 같이 LF를 CRLF로 변환하지 않고 바이너리 파일을 그대로 유지하기에 충분히 똑똑하다고 생각합니다.

요약하면이 전환에 대해 너무 걱정하지 않아도됩니다. 그러나 프로젝트를 타르볼로 보관하려는 경우 동료 코더는 CRLF가 아닌 LF 라인 터미네이터를 사용하는 것이 좋습니다. 당신이 얼마나 신경 쓰는지에 따라 (그리고 메모장을 사용하지 않는 것에 따라), 가능하다면 LF 리턴을 사용하도록 git을 설정할 수 있습니다 :)

부록 : CR은 ASCII 코드 13, LF는 ASCII 코드 10입니다. 따라서 CRLF는 2 바이트 인 반면 LF는 1입니다.

최신 git을 설치했는지 확인하십시오. git (버전 2.7.1)을 사용할 때
위와 같이 git config core.autocrlf false했지만 작동하지 않았습니다.
그런 다음 git를 업그레이드 할 때 작동합니다 (2.7.1에서 2.20.1로).

1. 메모장 ++에서 파일을 엽니 다.
2. 편집 / EOL 변환으로 이동하십시오.
3. Windows 형식을 클릭하십시오.
4. 파일을 저장하십시오.

OP의 질문은 Windows와 관련이 있으며 관리자가 작동하지 않으므로 디렉토리로 이동하거나 메모장 ++에서 파일을 실행하지 않으면 다른 사람을 사용할 수 없습니다.

C:\Program Files (x86)\Git\etc>git config --global core.autocrlf false

많은 텍스트 편집기를 사용하여로 변경할 수 LF있습니다. 아래 Atom 지침을 참조하십시오. 간단하고 명시 적입니다.

CRLF오른쪽 하단을 클릭하십시오 :

LF상단의 드롭 다운에서 선택하십시오 .

GNU / Linux 쉘 프롬프트에서 dos2unix & unix2dos 명령을 사용하면 MS Windows에서 온 파일을 쉽게 변환 / 포맷 할 수 있습니다

CRLF는 두 개의 다른 OS (Linux 및 Windows)에서 "코드"를 사용하는 동안 문제를 일으킬 수 있습니다. 내 파이썬 스크립트는 Linux docker container로 작성된 다음 Windows git-bash를 사용하여 푸시되었습니다. LF가 CRLF로 대체 될 것이라는 경고를 받았습니다. 나는 많은 생각을하지 않았지만 나중에 스크립트를 시작했을 때 말했다 /usr/bin/env: 'python\r': No such file or directory. 이제는 \r당신을위한 파급 효과입니다. Windows는 'CR'-캐리지 리턴을 '\ n'맨 위에 새 줄 문자로 사용 \n\r합니다. 그것은 당신이 고려해야 할 수도 있습니다.

Windows의 대부분의 도구는 텍스트 파일에서 LF 만 허용합니다. 예를 들어 다음 예제 콘텐츠 (파트)와 함께 '.editorconfig'라는 파일에서 Visual Studio의 동작을 제어 할 수 있습니다.

 indent_style = space
 indent_size = 2
 end_of_line = lf    <<====
 charset = utf-8

원래 Windows 메모장 만 LF에서 작동하지 않지만 사용할 수있는 적절한 간단한 편집기 도구가 있습니다!

따라서 Windows의 텍스트 파일에도 LF를 사용해야합니다. 이것은 나의 메시지이다, stronlgy는 추천했다! Windows에서 CRLF를 사용할 이유가 없습니다!

(같은 토론은 C / ++의 경로 포함에 \를 사용하고 있습니다. 헛소리입니다. 슬래시와 함께 #include <pathTo / myheader.h>를 사용하십시오. C / ++ 표준이며 모든 Microsoft 컴파일러가 지원합니다).

따라서 git의 올바른 설정은

git config core.autocrlf false

내 메시지 : dos2unix 및 unix2dos와 같은 오래된 사고 프로그램을 잊어 버려라. 팀에서 LF가 Windows에서 사용하기에 적합하다는 것을 명확히하십시오.