bash를 사용하여 Windows XP 시스템에서 git 실행 SVN에서 프로젝트를 내 보낸 다음 베어 리포지토리를 복제했습니다.
그런 다음 내보내기를 베어 리포지토리 디렉토리에 붙여 넣고 다음을 수행했습니다.
git add -A
그런 다음 메시지 목록을 얻었습니다.
LF는 CRLF로 대체됩니다
이 전환의 결과는 무엇입니까? 이것은 Visual Studio의 .NET 솔루션입니다.
답변
이 메시지는 core.autocrlf
Windows의 기본값이 올바르지 않기 때문 입니다.
개념은 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로 대체 될 것이다 “당신이 (갖는 말한다autocrlf
true
커밋 체크 아웃주기 후 =를 ) 유닉스 스타일의 LF를 잃게 Windows 스타일의 CRLF로 대체 됨). Git은 윈도우에서 유닉스 스타일의 LF를 사용할 것을 기대하지 않습니다.
경고 ” CRLF를 LF로 대체 될 것이다 “당신은 (가지고 있다고 autocrlf
= input
A는 (은 유닉스 스타일의 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.autocrlf
true로 설정 되면 , git가 생각하는 git repo에 파일을 텍스트 파일로 추가 할 때마다 모든 CRLF 줄 끝이 커밋에 저장되기 전에 LF로 바뀝니다. 언제든지 너를git checkout
무언가를 , 모든 텍스트 파일은 자동으로 LF 줄 끝을 CRLF 끝으로 변환합니다. 따라서 줄 끝 스타일이 항상 일관되게 LF이므로 각 편집기가 줄 끝 스타일을 변경하기 때문에 커밋이 커지지 않고 다른 줄 끝 스타일을 사용하는 플랫폼에서 프로젝트를 개발할 수 있습니다.
이 편리한 변환의 부작용, 그리고 이것이 당신이보고있는 경고에 대한 것입니다, 당신이 만든 텍스트 파일이 원래 CRLF 대신에 LF 엔딩을 가지고 있다면, 평소와 같이 LF와 함께 저장되지만, 체크 될 때 나중에 CRLF 엔딩이 생깁니다. 일반 텍스트 파일의 경우 일반적으로 좋습니다. 이 경우 경고는 “정보 용”이지만 git이 이진 파일을 텍스트 파일로 잘못 평가하는 경우 git이 이진 파일을 손상시킬 수 있으므로 중요한 경고입니다.
경우 core.autocrlf
false로 설정되어있는 텍스트 파일이-그대로 체크되도록, 더 라인 끝 변환은 이제까지 수행되지 않습니다. 모든 개발자가 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
참고 : 로컬 변경 사항이 제거되므로이를 수행하기 전에이를 변경하십시오.
답변
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 파일을 열고 safecrlf
false로 설정하십시오.
[core]
autocrlf = input
safecrlf = false
그것은 줄 char의 끝을 분명히 무시하게 할 것입니다 (어쨌든 나를 위해 일했습니다).
답변
이 주제에 대해 이야기 할 때 줄 끝에 관한 GitHub의 기사 가 일반적으로 언급됩니다.
자주 권장되는 core.autocrlf
구성 설정 사용에 대한 개인적인 경험 은 매우 혼합되었습니다.
Cygwin과 함께 Windows를 사용하고 있으며 다른 시간에 Windows와 UNIX 프로젝트를 모두 처리합니다. 내 Windows 프로젝트조차도 때때로 bash
쉘 스크립트를 사용하는데 , 이는 UNIX (LF) 줄 끝이 필요합니다.
GitHub 사용 권장 core.autocrlf
Cygwin에서 완벽하게 작동하는 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의 기여자는이 프로젝트로 작업 할 때 줄 끝에 문제가 없어야합니다.