programing

Git으로 CRLF(캐리지 리턴, 라인 피드)를 처리하는 전략은 무엇입니까?

abcjava 2023. 4. 16. 14:17
반응형

Git으로 CRLF(캐리지 리턴, 라인 피드)를 처리하는 전략은 무엇입니까?

CRLF 엔딩 행으로 파일을 커밋하려고 했지만 실패했습니다.

나는 하루 종일 윈도 컴퓨터로 다른 전략을 시도했고 Git 사용을 중단하고 대신 Mercurial을 시도하려고 했다.

CRLF 회선 엔딩을 적절하게 처리하는 방법

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

자세한 내용은 github:help's guide to adjusting line ends를 참조하십시오.

Git을 사용하면 파일 내의 텍스트 속성을 사용하여 직접 repo의 줄 끝 속성을 설정할 수 있습니다.이 파일은 repo에 커밋되며, 이 파일은 리포에 덮어씁니다.core.autocrlf을 사용하면 git 모든 할 수 .

그래서

이 방법의 장점은 엔드 오브 라인 구성이 저장소와 함께 이동하며 공동작업자가 적절한 글로벌 설정을 가지고 있는지 여부에 대해 걱정할 필요가 없다는 것입니다.

다음은 파일 예시입니다.

# 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 파일을 편리하게 모을 수 있습니다.시작하는데 도움이 됩니다.

를 작성 또는 조정한 후에는 한 번만 행 끝의 정규화를 실행해야 합니다.

GitHub Desktop 앱은 앱에서 프로젝트의 Git repo를 연 후에 제안하고 파일을 만들 수 있습니다.이를 수행하려면 오른쪽 상단 모서리에 있는 톱니바퀴 아이콘을 클릭합니다.> [ Repository settings ... 。> 행의 끝과 어트리뷰트.권장 사항을 추가하라는 메시지가 표시되고 동의하면 앱도 저장소에 있는 모든 파일의 정규화를 수행합니다.

마지막으로, Mind the End of Your Line 기사는 더 많은 배경을 제공하고 Git이 가까운 문제에 대해 어떻게 발전해 왔는지 설명한다.나는 이것을 꼭 읽어야 한다고 생각한다.

EGit 또는 JGit(Eclipse 및 TeamCity와 같은 툴 사용)을 사용하여 변경을 커밋하는 사용자가 팀에 있을 것입니다.@gatinueta가 이 답변의 코멘트에서 설명한 바와 같이, 당신은 운이 없다.

팀에 Egit 또는 JGit과 함께 작업하는 사람이 있는 경우 이 설정은 완전히 만족스럽지 않습니다.이러한 툴은 .timeout Attribute를 무시하고 CRLF 파일 https://bugs.eclipse.org/bugs/show_bug.cgi?id=342372에 행복하게 체크인하기 때문입니다.

SourceTree와 같은 다른 클라이언트에서 변경을 커밋하도록 하는 방법이 있습니다.당시 우리 팀은 많은 사용 사례에서 이 툴을 Eclipse의 EGit보다 선호했습니다.

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

행의 끝을 변환하지 말아 주세요.데이터를 해석하는 것은 VCS가 할 일이 아닙니다.데이터를 저장하고 버전만 설정합니다.현대의 모든 텍스트 편집기는 두 줄의 끝부분을 모두 읽을 수 있습니다.

은 거의 '원하고 있다'고 생각하고 있습니다.autocrlf=input네가 정말 뭘 하고 있는지 모르는 한 말이야

그 외의 콘텍스트는 다음과 같습니다.

중 하나여야 .core.autocrlf=true의 엔딩이나 DOS의 엔딩이 에 드신다면core.autocrlf=inputsys-newlines 를 사용하는 는, 「」를 해 주세요.어느 경우든 Git 저장소에는 LF만 있으며, 이것이 올바른 것입니다." " 의한 core.autocrlf=false자동 휴리스틱이 일부 바이너리를 텍스트로 잘못 감지하면 타일이 손상된다는 것입니다.so,는,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 또는 Linux/UNIX의 경우 »trueMS Windows （ 장장 ms ms ）

    git config --global core.autocrlf input

  3. "Set" (설정)core.safecrlf로로 합니다.truewarn( sing 행 의 역방향으로 :).

    git config --global core.safecrlf true

B. 또는 저장소별 설정

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

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

  2. .gitattributes your repository(로 파일 전송)

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

바이너리 파일은 걱정하지 마세요.G는 바이너리 파일에 대해 충분히 스마트합니다.

safecrlf/autocrlf 변수에 대한 자세한 정보

--- UPDATE 3 --- (UPDATE 2와 경합하지 않음)

사용자가 하는 것을 .CRLF는 Linux/mac에서 하는 것을 합니다.LF텍스트 파일에 있습니다.저장소 유지관리자의 관점에서 답변 제공:

저에게 있어서 가장 좋은 전략(해결해야 할 문제가 적음)은 윈도 전용 프로젝트라도 모든 텍스트 파일을 git repo 안에 보관하는 것입니다.그런 다음 고객이 원하는 라인엔딩 스타일을 자유롭게 작업할 수 있도록 합니다.단, 고객이 원하는 라인엔딩 스타일을 선택할 수 있도록 합니다.core.autocrlf커밋을 위해 파일을 스테이징하는 동안 전략을 존중하는 속성 값(Repo 시 LF)

스테이징은 많은 사람들이 뉴라인 전략이 어떻게 작동하는지 이해하려고 할 때 혼란스럽게 만드는 것입니다.올바른 값을 선택하기 전에 다음 사항을 확인해야 합니다.core.autocrlf★★★★

  • 커밋(스테이징)을 위한 텍스트 파일을 추가하는 것은 파일을 내부의 다른 위치에 복사하는 것과 같습니다..git/변환된 행 엔딩이 있는 서브 디렉토리(에 따라 다름)core.autocrlf값을 지정합니다).이 모든 것은 로컬에서 이루어집니다.
  • core.autocrlf이는 질문에 대한 답변을 제공하는 것과 같습니다(모든 OS에서 정확히 동일한 질문). "Git-client:
    • a. 리모콘에서 repo 변경을 체크아웃(풀아웃)할 때 LF에서 CRLF로 변환한다.
    • b. commit용 파일을 추가할 때 CRLF에서 LF로 변환합니다.
  • 가능한 답변(값)은 다음과 같습니다.
    • false:"상기 중 어느 것도 하지 마십시오.",
    • input:"b만 실행"
    • true: "a와 b를 실행합니다."
    • "do only a"는 존재하지 않습니다.

다행히도.

  • Windows: git "Git "Directions" (Windows:core.autocrlf: true , Linux/mac:core.autocrlf: false)는 LF만의 repo 전략과 호환됩니다.
    즉, Windows 클라이언트는 저장소를 체크아웃할 때 기본적으로 CRLF로 변환되고 커밋을 추가할 때 LF로 변환됩니다.Linux 클라이언트는 기본적으로 변환을 수행하지 않습니다.이론상으로는 당신의 평판이 유지된다.

유감스럽지만:

  • GIT를 수 .core.autocrlf
  • 「 lf-repo 」는, 「lf-repo 」로, 「rf-repo」는 「rf-repo」로, 「rf-repo」는 「rf-repo」를 사용합니다.core.autocrlf=falseCRLF를 사용하다

위의 클라이언트가 커밋한 ASAP non-lf 텍스트파일을 검출하려면 , ---update 2 ---:(에 기재되어 있는 순서에 따릅니다.git grep -I --files-with-matches --perl-regexp '\r' HEAD명령을 사용하여 --with-libpcreflag를 합니다.

그리고 여기에 함정이 있습니다.저는 관리자로서git.autocrlf=input잘못 커밋된 파일을 다시 커밋하는 것만으로 수정할 수 있습니다.그리고 커밋 텍스트 "잘못된 커밋 파일 수정"을 제공합니다.

.gitattributes황하고고있있있모르는 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

질문:.그런데 왜 우리는 새로운 라인에서의 대처 전략에 전혀 관심이 없는 것일까요?

답변: 단일 문자 변경 커밋을 피하기 위해 5000줄 변경으로 표시하십시오.단, 변경을 수행한 클라이언트가 crlf에서 lf(또는 그 반대)로 파일을 자동 변환한 후 커밋용으로 추가합니다.이것은 분쟁 해결이 수반될 때 다소 고통스러울 수 있다.또는 경우에 따라서는 그것이 불합리한 갈등의 원인이 될 수도 있다.

--- UPDATE 2 ---

대부분의 경우 git 클라이언트의 dafaults는 동작합니다.Windows 전용 클라이언트만 있는 경우에도 Linux 전용 클라이언트 또는 둘 다입니다.다음과 같습니다.

  • §: core.autocrlf=true체크아웃 시 행을 CRLF로 변환하고 파일 추가 시 행을 LF로 변환하는 것을 의미합니다.
  • Linux: core.autocrlf=input체크아웃 시 행을 변환하지 않고(파일이 LF로 커밋될 것으로 예상되므로 필요 없음), 파일 추가 시 행을 LF로 변환합니다(--update3 -- : : 이것은 다음과 같습니다).false★★★★★★★★★★★★★★★★★★★★★★★」

속성은 다른 범위에서 설정할 수 있습니다.는 이 것이 좋습니다.--global마지막으로 설명되는 IDE 문제를 피하기 위해 scope를 선택합니다.

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 config --global core.autocrlf false (Windows 전용 클라이언트가 있는 경우) 제안 문서와 대조됩니다.false로 설정하면 repo에 CRLF가 있는 파일이 커밋됩니다.하지만 진짜 이유는 없어요.프로젝트를 Linux 사용자와 공유할 필요가 있는지 여부를 알 수 없습니다.또한 기본값이 아닌 프로젝트에 참여하는 각 클라이언트에 대해 한 단계 더 진행됩니다.

「」등)에 는, 과 같이 설명합니다.*.bat *.sh CRLF를 사용할 수 .gitattributes

요약하자면 베스트 프랙티스는 다음과 같습니다.

  • 모든 비바이너리 파일이 Git repo에서 LF로 커밋되는지 확인합니다(기본 동작).
  • 명령어를 하여 CRLF로 파일이 는 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로 100%를..gitattributes할 수 git 클라이언트는 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를 사용하여 모든 텍스트파일을 잘못 커밋합니다.이것은 표준 git 클라이언트의 동작에 반하여 업데이트/머지 중에 나중에 많은 문제를 일으킵니다.따라서 일부 파일은 원래대로 되돌릴 때에도 다르게 표시됩니다(비록 그렇지 않습니다).
합니다.정확한 은 넷빈입니다..gitattributes당신의 프로젝트에 적용하세요.

에 다음 에 행 할 수 .git grep -I --files-with-matches --perl-regexp '\r' HEAD

나는 몇 시간 동안을 할애하여 이 시스템을 최대한 활용할 수 있는 방법을 생각해냈다. .gitattributes믿을 수 없다는 걸 깨달았어요
JGit(JGit, JGit(JGit).gitattributesLF에 관한 것입니다.

하다, 하다, 하다,anti-CRLF소독제

「」를 사용합니다.core.autocrlf=falseVisual Studio 2010 프로젝트에서 파일을 체크 아웃하자마자 모든 파일이 업데이트된 것으로 표시되지 않도록 했습니다.개발팀의 다른 2명도 Windows 시스템을 사용하고 있기 때문에 혼합환경은 발생하지 않았습니다만, 레포지토리에 부속된 디폴트 설정에서는, 항상 클로닝 직후에 모든 파일이 갱신되고 있는 것으로 표시되어 있었습니다.

결론은 고객님의 환경에 적합한 CRLF 설정을 찾는 것입니다.의 다른 를 설정하기 autocrlf = true더 나은 결과를 얻을 수 있습니다.

20년이 넘었는데도 OS 간의 라인 엔딩 불균형을 겪고 있습니다.슬프네요.

.core.autocrlf에서 ""로true ,, 이, 이, 이도 봐주세요.core.safecrlf★★★★★★ 。

사실 이 말은core.safecrlf이미 저장소에 설정되어 있을 수 있습니다.그 이유는 다음과 같습니다.

이것이 코어의 현재 설정에 해당되지 않는 경우.autocrlf, git은 파일을 거부합니다.

이 경우 텍스트에디터가 행 끝을 일관되게 사용하도록 설정되어 있는지 확인할 수 있습니다.텍스트 파일에 LF 행과 CRLF 행의 엔딩이 혼재하는 경우 문제가 발생할 수 있습니다.

마지막으로, Windows에서 단순히 "제공받은 것을 사용하고" LF 종단 회선을 사용하도록 권장하는 것은 해결보다 더 많은 문제를 일으킬 것이라고 생각합니다.Git은 위의 옵션을 가지고 있기 때문에 회선 엔딩을 센스 있게 처리하려고 합니다.

이는 Mac 또는 Linux 사용자와 코드를 공유하는 Windows 및 Visual Studio 사용자를 위한 두 가지 옵션입니다.자세한 설명은 gitattributes 매뉴얼을 참조하십시오.

* text=자동

의 레포에서.gitattributes일일: :

*   text=auto

모든 됩니다.LF레포의 행 말미에 표시됩니다.

, 의 operating system operating system, operating system, operating system, operating system)에 따라서 다릅니다.core.eol이 설정으로 됩니다.LF 또는 UNIX의 CRLFWindows の windows windows windows 。

이것은 Microsoft 의 설정입니다.NET 저장소 사용.

예:

Hello\r\nWorld

레포에서는 항상 다음과 같이 정규화됩니다.

Hello\nWorld

체크아웃 시 Windows의 작업 트리는 다음과 같이 변환됩니다.

Hello\r\nWorld

체크아웃 시 Mac의 작업 트리는 다음과 같이 유지됩니다.

Hello\nWorld

포함되어 있는 : " " " " " " " " " " " " " " " 。git status다음 번에 파일을 변경할 때 이 파일이 완전히 수정된 것으로 표시되므로 나중에 다른 사용자가 변경 내용을 병합해야 하는 번거로움이 있을 수 있습니다.자세한 내용은 줄 끝을 변경한 후 저장소 새로 고침을 참조하십시오.

core.autocrlf = true

iftext 않습니다..gitattributes은 ★★, Git을 합니다.core.autocrlf파일을 변환해야 하는지 여부를 결정하는 구성 변수입니다.

사용자의 Windows " " " 입니다.git config --global core.autocrlf true좋은 옵션입니다.

  • 은 음음음음음음음음음음 되어 있습니다.LF줄 끝은 repo에 추가된 경우에만 표시됩니다.레포에 정규화되지 않은 파일이 있는 경우, 이 설정은 해당 파일에 영향을 주지 않습니다.
  • 이 든모 are are are are are are are are all로 변환됩니다.CRLF이치노

이 접근방식의 문제는 다음과 같습니다.

  • 를 사용하고 있는 는,autocrlf = inputLF. 은 여전히 른른른른izedizedizedized로 정상화되기 때문입니다. 왜냐하면 당신의 약속은 다음 방법으로 정상화될 것이기 때문입니다.LF행의 끝
  • 를 사용하고 있는 는,core.autocrlf = falseLF에는, 「」라고 하는 파일이 있습니다.CRLF줄바꿈을 리포에 넣습니다.
  • 는 "Mac"을 사용합니다.autocrlf = input 수 .CRLF 엔딩로부터)core.autocrlf = false.

이것은 회피책일 뿐입니다.

일반적인 경우 git에 동봉된 솔루션을 사용하십시오.대부분의 경우 이 기능은 훌륭합니다..gitattributes를 설정하여 Windows 및 Unix 기반 시스템에서 개발을 공유하는 경우 LF로 강제 전환합니다.

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

일부 설정은 LF 포맷에 영향을 주지 않고 기계 내부에서 작성되었습니다.따라서 일부 파일은 작은 파일을 변경할 때마다 글로벌하게 LF로 변경되었습니다.

솔루션:

Windows-머신:모든 것을 있는 그대로 두어라.디폴트 윈도 '외톨이' 개발자라면 "광범위한 세상에 다른 시스템은 없죠?"라는 식으로 대처해야 하기 때문에 아무 것도 신경 쓰지 마세요.

Unix-Machines

  1. 행에 합니다.[alias] 변경된/새로운 파일을 합니다.이 명령어는 변경된(변경된/새로운) 파일입니다.

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

  2. 변경된 모든 파일을 dos 형식으로 변환합니다.

    unix2dos $(git lc)

  3. 옵션으로...

    1. 이 작업을 위한 git 훅을 만들어 프로세스를 자동화합니다.

    2. 시키고, 「」를 합니다.grep★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★ §:

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

    3. 추가 숏컷을 사용하여 더욱 편리하게 이용하실 수 있습니다.

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

      ...그리고 변환된 것을 타이핑하여 발사한다.

      git c2dos

언급URL : https://stackoverflow.com/questions/170961/whats-the-strategy-for-handling-crlf-carriage-return-line-feed-with-git

반응형

'programing' 카테고리의 다른 글

크로스 조인이나 데카르트 제품을 엑셀로 하는 방법이 있나요?  (0) 2023.04.16
문자열의 큰따옴표 이스케이프  (0) 2023.04.16
Objective-C에서의 NSString 대문자와 소문자 변경  (0) 2023.04.16
Pod 설치는 "CocoaPods Master repo 설정"에 머무르고 있습니다.  (0) 2023.04.16
iOS 8에서 탐색 모음, 색조 및 제목 텍스트 색상  (0) 2023.04.16

'programing'의 다른글

  • 현재글Git으로 CRLF(캐리지 리턴, 라인 피드)를 처리하는 전략은 무엇입니까?

관련글

댓글

티스토리툴바