카테고리 보관물: Git

Git

Git을 사용한 최고의 CRLF (캐리지 리턴, 줄 바꿈) 처리 전략은 무엇입니까? 줄이있는 파일을 커밋하려고했지만 실패했습니다. 나는 하루 종일 Windows

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.autocrlfinput리눅스 / UNIX 나 true) MS Windows에서 (저장소 또는 글로벌

git config --global core.autocrlf input

3) [선택 사항] core.safecrlftrue(정지) 또는 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 사용자 와 코드를 공유하는 WindowsVisual 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.