git 한글 깨짐 해결: git status 한글 파일명 \354\225\210, 커밋 메시지·diff 깨짐 원인별 정리

작성 0xmote · 2026년 10월 29일 · 16분 읽기 · 수정 2026년 10월 29일 중급 가이드

이 글의 핵심

Git에서 한글이 깨져 보이는 현상은 원인이 하나가 아닙니다. 파일 이름이 \354\225\210 같은 숫자로 나오는 것은 깨진 게 아니라 Git의 기본 이스케이프(core.quotepath)이고, 윈도우 PowerShell에서 ?덈뀞 같은 글자가 나오는 것은 터미널 코드페이지 문제이며, 같은 이름의 파일이 두 개로 보이는 것은 macOS의 NFD 정규화, diff 안의 내용만 깨지는 것은 파일 자체가 CP949로 저장된 경우입니다. 이 글은 각 원인을 실제 출력과 함께 구분하는 방법과 원인별 설정을 정리합니다.

“git 한글 깨짐”으로 검색하면 git config --global core.quotepath false 한 줄이 가장 먼저 나옵니다. 이 설정으로 해결되는 경우도 많지만, 그대로 따라 했는데 여전히 깨지는 경우가 그만큼 많습니다. Git에서 한글이 이상하게 보이는 현상은 원인이 최소 다섯 가지이고, 서로 다른 계층에서 일어나기 때문입니다. 파일 이름을 Git이 일부러 이스케이프한 것, 터미널이 UTF-8 바이트를 다른 인코딩으로 읽은 것, 커밋 메시지가 애초에 다른 인코딩으로 저장된 것, 파일 이름의 유니코드 정규화 형태가 다른 것, 파일 내용 자체가 CP949인 것은 모두 “한글이 깨진다”로 보이지만 고치는 곳이 전부 다릅니다.

이 글은 증상을 보고 어느 경우인지 판단하는 방법을 먼저 정리하고, 원인별로 왜 그런 일이 생기는지와 설정을 설명합니다. 글에 나오는 출력 중 “실제 출력”이라고 적은 것은 윈도우 11의 Git for Windows 2.32와 PowerShell 5.1에서 임시 저장소를 만들어 실행한 결과입니다. 문자 인코딩 자체(UTF-8과 CP949의 바이트 구조, 깨진 글자 모양으로 원인을 추정하는 법)는 한글이 깨지는 이유 글에서 자세히 다룹니다.

기준 환경: Git 2.x(working-tree-encoding은 2.18 이상), 윈도우 10/11의 Git for Windows와 PowerShell 5.1·명령 프롬프트·Git Bash, macOS 기본 터미널, 우분투 24.04. 최근 Git 버전에서도 아래 설정들의 기본값은 바뀌지 않았습니다.

증상으로 원인 구분하기

보이는 모습	어디서	원인
`"\354\225\210\353\205\225.txt"`	`git status`, `git diff` 등의 파일 이름	깨진 것이 아니라 Git의 경로 이스케이프(`core.quotepath`)
`?덈뀞.txt`, `?쒓? 而ㅻ컠` 같은 한자 섞인 글자	윈도우 명령 프롬프트·PowerShell	터미널이 UTF-8 출력을 CP949로 해석
커밋 메시지만 깨짐, 파일 이름은 정상	`git log`	메시지가 CP949로 저장됐거나, 출력 인코딩·페이저 설정 문제
같은 이름의 파일이 두 개로 보이거나, 맥에서 커밋한 파일이 계속 변경됨으로 나옴	맥과 윈도우·리눅스가 섞인 저장소	유니코드 정규화(NFD와 NFC) 차이
파일 이름은 정상인데 diff 안의 한글만 `��`, `ù` 같은 글자로 나옴	`git diff`, `git show`	파일 자체가 CP949(EUC-KR)로 저장됨

여러 원인이 겹칠 수도 있습니다. 예를 들어 윈도우 PowerShell에서 core.quotepath를 끄지 않은 상태라면 처음에는 8진수 이스케이프가 보이고, 이것을 끄고 나면 다음 단계인 코드페이지 문제가 드러납니다. 그래서 “quotepath를 껐더니 다른 모양으로 깨진다”는 일이 생깁니다. 위에서부터 하나씩 해결하면 됩니다.

파일 이름이 \354\225\210 으로 나올 때: core.quotepath

한글 이름의 파일을 새로 만들고 git status를 실행하면 이렇게 나옵니다. 실제 출력입니다.

$ git status --short
?? "\354\225\210\353\205\225.txt"

이것은 깨진 것이 아닙니다. 안녕.txt라는 이름의 UTF-8 바이트 EC 95 88 EB 85 95를 Git이 8진수(\354 = 0xEC)로 적은 것입니다. 바이트가 그대로 보존되어 있으므로 되살리는 것도 간단합니다. 리눅스나 Git Bash에서 printf에 넣어 보면 원래 이름이 나옵니다.

$ printf '\354\225\210\353\205\225.txt\n'
안녕.txt

Git이 이렇게 하는 이유는 Git 입장에서 파일 이름은 “바이트의 나열”일 뿐이고 그 바이트가 어떤 인코딩인지 알 수 없기 때문입니다. 리눅스 파일 시스템은 파일 이름에 거의 아무 바이트나 허용하므로, 어떤 저장소에는 UTF-8 이름이, 다른 저장소에는 EUC-KR 이름이 들어 있을 수 있습니다. 이런 바이트를 그대로 터미널에 내보내면 터미널을 깨뜨리거나 출력을 파싱하는 스크립트가 오작동할 수 있으므로, Git은 기본값(core.quotepath=true)에서 0x80 이상의 바이트를 가진 경로를 큰따옴표로 감싸고 해당 바이트를 8진수로 바꿔 출력합니다. 영어권 개발자에게는 거의 보이지 않는 동작이라 기본값이 지금까지 유지되고 있습니다.

파일 이름이 UTF-8이고 터미널도 UTF-8이라면 이 이스케이프를 끄는 것이 맞습니다.

git config --global core.quotepath false

같은 저장소에서 끄고 실행한 실제 출력입니다.

$ git -c core.quotepath=false status --short
?? 안녕.txt

git -c 설정=값은 그 명령 한 번에만 설정을 적용하므로, 전역 설정을 바꾸기 전에 효과를 미리 보고 싶을 때 쓰기 좋습니다. 이 설정은 git status, git diff, git ls-files, git log --stat 등 경로를 출력하는 대부분의 명령에 영향을 줍니다. 탭이나 줄바꿈처럼 제어 문자가 들어간 이름은 false로 해도 여전히 이스케이프되는데, 이는 터미널 보호를 위한 의도된 동작입니다.

스크립트에서 Git이 출력하는 파일 목록을 처리한다면 이 설정에 기대지 말고 -z 옵션을 쓰는 것이 좋습니다. git ls-files -z, git diff --name-only -z, git status --porcelain -z는 경로를 이스케이프 없이 NUL 문자로 구분해서 내보내므로, 다른 사람의 컴퓨터에서 core.quotepath가 어떻게 설정되어 있든 같은 결과를 얻습니다.

직접 확인한 결과도 적어 둡니다. macOS(Apple Git 2.54.0)의 빈 저장소에서 안녕.txt를 만들고 git add 후 git status --short를 실행하면 A "\354\225\210\353\205\225.txt"로 나옵니다. 같은 상태에서 git -c core.quotepath=false status --short를 실행하면 A 안녕.txt로 바뀝니다. 파일은 그대로이고 출력 방식만 달라지는 것이므로, 숫자 이스케이프는 깨진 것이 아니라는 설명이 맞습니다. 윈도우 코드페이지와 CP949 항목은 이 맥에서 재현하지 못했습니다.

윈도우에서 ?덈뀞 처럼 깨질 때: 터미널 코드페이지

core.quotepath를 끄고 나서 윈도우 PowerShell이나 명령 프롬프트에서 아래처럼 보인다면 다음 단계의 문제입니다.

?덈뀞.txt
?쒓? 而ㅻ컠 硫붿떆吏

위 출력은 PowerShell 5.1에서 [Console]::OutputEncoding을 한국어 윈도우 기본값인 CP949(웹 이름 ks_c_5601-1987)로 둔 상태에서, git ls-files와 git log --format=%s 출력을 변수에 받아 실행한 실제 결과입니다. 원래 내용은 안녕.txt와 한글 커밋 메시지입니다. Git for Windows는 파일 이름과 메시지를 UTF-8로 내보내는데, PowerShell이 외부 프로그램의 출력을 받을 때는 [Console]::OutputEncoding에 지정된 인코딩으로 해석합니다. UTF-8 바이트를 CP949로 읽으면 바이트 경계가 어긋나서 덈, 而, 硫 같은 엉뚱한 한글·한자가 섞인 문자열이 나옵니다. 이 패턴(드물게 쓰이는 한글과 한자가 섞여 나오는 모양)이 보이면 거의 확실히 “UTF-8을 CP949로 읽은” 경우입니다.

같은 세션에서 인코딩을 UTF-8로 바꾸고 다시 실행하면 정상으로 나옵니다. 역시 실제 출력입니다.

PS> [Console]::OutputEncoding = [System.Text.Encoding]::UTF8
PS> git -c core.quotepath=false ls-files
안녕.txt
PS> git log -1 --format=%s
한글 커밋 메시지

증상이 상황에 따라 다르게 보일 수 있다는 점도 알아 두면 좋습니다. Git for Windows는 콘솔 창에 직접 출력할 때 자체적으로 문자 변환을 처리하는 경우가 있어서, 같은 명령을 그냥 실행하면 정상인데 | Select-String으로 파이프하거나 $x = git ...처럼 변수에 담거나 파일로 리다이렉트할 때만 깨지기도 합니다. 출력이 PowerShell을 거치는 순간 위의 인코딩 규칙이 적용되기 때문입니다. 버전과 터미널 조합에 따라 차이가 있으므로, “가끔만 깨진다”면 이 경로 차이를 의심해 볼 만합니다.

환경별 설정:

Git Bash(mintty): 기본 문자 집합이 UTF-8이라 core.quotepath만 끄면 대부분 바로 정상입니다. Git for Windows 설치 시 함께 들어오는 터미널이므로, 한글 문제를 피하는 가장 간단한 선택입니다.
명령 프롬프트(cmd): chcp 65001로 현재 창의 코드페이지를 UTF-8로 바꿉니다. 창을 닫으면 원래대로 돌아갑니다.
PowerShell 5.1: 아래 두 줄을 프로필에 넣어 두면 매번 입력하지 않아도 됩니다. 프로필 파일 위치는 $PROFILE로 확인할 수 있고, 파일이 없으면 New-Item -ItemType File -Force $PROFILE로 만듭니다.

[Console]::OutputEncoding = [System.Text.Encoding]::UTF8
$OutputEncoding = [System.Text.Encoding]::UTF8

첫 줄은 외부 프로그램의 출력을 읽을 때의 인코딩이고, 두 번째 줄은 PowerShell이 외부 프로그램에 파이프로 문자열을 넘길 때의 인코딩입니다. echo 한글 | git hash-object --stdin처럼 PowerShell에서 Git으로 한글을 넘기는 경우가 있다면 두 번째 줄도 필요합니다.

윈도우 설정의 “Beta: 세계 언어 지원을 위해 Unicode UTF-8 사용” 옵션을 켜면 시스템 전체의 기본 코드페이지가 65001로 바뀌어 위 설정 없이도 해결됩니다. 하지만 CP949를 전제로 만든 오래된 프로그램(일부 국내 업무용 프로그램, 한글 경로를 다루는 구형 설치 프로그램 등)의 한글이 반대로 깨질 수 있어서, 시스템 전체 설정보다는 터미널별 설정이 부작용이 적습니다. 이 옵션을 켰다가 다른 프로그램에서 문제가 생기면 같은 위치에서 끄고 재부팅하면 원래대로 돌아옵니다.

git log에서 커밋 메시지만 깨질 때

파일 이름은 정상인데 git log의 커밋 메시지만 깨진다면, 메시지가 저장된 인코딩과 출력 인코딩 중 하나가 어긋난 것입니다. 관련 설정은 두 가지이고, 이름 때문에 오해가 많습니다.

i18n.commitEncoding: 커밋을 만들 때 “이 메시지는 이 인코딩으로 쓰였다”는 표시(커밋 객체의 encoding 헤더)를 남깁니다. Git이 메시지를 이 인코딩으로 변환해 주는 것이 아닙니다. 기본값은 UTF-8이고, UTF-8일 때는 헤더 자체를 기록하지 않습니다.
i18n.logOutputEncoding: git log, git show 등이 메시지를 출력할 때 변환할 인코딩입니다. 커밋에 encoding 헤더가 있으면 그 인코딩에서 이 인코딩으로 변환하고, 헤더가 없으면 UTF-8로 간주합니다. 지정하지 않으면 i18n.commitEncoding 값을 따릅니다.

오래된 블로그 글 중에는 윈도우 명령 프롬프트에 맞추겠다며 i18n.logOutputEncoding을 cp949로 바꾸라는 조언이 있습니다. 터미널이 정말 CP949일 때는 그 효과가 있지만, Git Bash나 VS Code 터미널처럼 UTF-8인 곳에서는 오히려 메시지를 깨뜨립니다. 정상적인 UTF-8 커밋에 이 설정을 걸고 출력을 UTF-8로 읽은 실제 결과입니다.

$ git log -1 --format=%s
한글 커밋 메시지

$ git -c i18n.logOutputEncoding=cp949 log -1 --format=%s
�ѱ� Ŀ�� �޽���

� 기호가 섞여 나오는 이 모양은 “CP949 바이트를 UTF-8로 읽은” 경우의 전형입니다. 앞 절의 ?덈뀞(UTF-8을 CP949로 읽음)과 방향이 반대라서 모양도 다릅니다. 예전에 이 설정을 바꿨다면 git config --global --unset i18n.logOutputEncoding으로 지우고 터미널 쪽을 UTF-8로 맞추는 편이 일관됩니다. 현재 값은 git config --show-origin --get-all i18n.logOutputEncoding으로 어느 파일에 설정되어 있는지까지 확인할 수 있습니다.

커밋 메시지가 애초에 CP949로 저장된 경우도 있습니다. 오래된 도구나 CP949로 저장하는 편집기로 커밋 메시지를 작성하면, Git은 그 바이트를 변환 없이 그대로 커밋에 담고 encoding 헤더도 남기지 않습니다. 그러면 Git은 이 메시지를 UTF-8로 간주하고 출력하므로 어디서 보든 깨집니다. 이 경우 설정으로는 고칠 수 없고, 볼 때 변환하는 수밖에 없습니다.

git log --format='%h %s' | iconv -f cp949 -t utf-8

git log를 그냥 실행했을 때만 깨지고 git log | cat으로는 정상이라면, 원인은 Git이 아니라 페이저(less)입니다. 이때는 less가 UTF-8로 해석하도록 환경 변수를 지정합니다. Git Bash라면 ~/.bashrc에, 윈도우 환경 변수로 지정하려면 사용자 환경 변수에 추가합니다. 윈도우 환경 변수 등록 방법은 윈도우 PATH 환경 변수 설정 글과 같은 화면을 쓰면 됩니다.

export LESSCHARSET=utf-8

같은 이름의 파일이 두 개로 보일 때: macOS의 NFD와 NFC

맥에서 만든 한글 파일을 윈도우나 리눅스에서 받았더니 같은 이름의 파일이 두 개 생겼다거나, 맥 사용자가 커밋한 파일이 다른 사람의 컴퓨터에서 지울 수 없는 상태로 남는 문제가 있습니다. 원인은 유니코드 정규화입니다.

한글 “한”은 유니코드에서 두 가지로 표현할 수 있습니다. 완성형 글자 하나(U+D55C)로 쓰는 NFC와, 초성 ㅎ·중성 ㅏ·종성 ㄴ 세 개의 자모(U+1112, U+1161, U+11AB)로 쓰는 NFD입니다. 화면에는 똑같이 “한”으로 보이지만 바이트는 완전히 다릅니다. 윈도우와 리눅스는 대부분 NFC를 쓰고, macOS는 파일 시스템과 일부 앱이 파일 이름을 NFD로 다루는 경우가 많습니다. 예전 HFS+ 파일 시스템은 파일 이름을 강제로 NFD로 바꿔 저장했고, 지금의 APFS는 정규화 형태를 보존하지만 비교할 때는 둘을 같은 이름으로 취급합니다.

윈도우의 NTFS는 정규화를 하지 않기 때문에 NFC 이름과 NFD 이름을 서로 다른 파일로 저장합니다. 같은 폴더에 두 형태의 한글.txt를 만들고 git status를 실행한 실제 출력입니다.

$ git -c core.quotepath=false status --short
?? 한글.txt
?? 한글.txt

$ git status --short
?? "\341\204\222\341\205\241\341\206\253\341\204\200\341\205\263\341\206\257.txt"
?? "\355\225\234\352\270\200.txt"

core.quotepath를 끄면 똑같은 이름 두 개로 보여서 원인을 알 수 없지만, 켜 두면 차이가 드러납니다. 이 점이 판단 기준이 됩니다. 현대 한글 완성형 글자(가~~힣)는 UTF-8로 EA~~ED로 시작하므로 8진수로 \352~~\355로 시작합니다. 반면 NFD의 한글 자모(U+1100~~U+11FF)는 E1 84~~E1 87로 시작하므로 \341\204~~\341\207 패턴이 반복됩니다. 저장소에서 NFD 이름을 찾고 싶다면 이스케이프를 켠 상태로 검색하면 됩니다.

git -c core.quotepath=true ls-files | grep '[\]341[\]20[4-7]'

Git에는 이 문제를 위한 core.precomposeunicode 설정이 있습니다. true이면 macOS에서 Git이 파일 시스템에서 읽은 NFD 이름을 NFC로 바꿔서 다루므로, 맥에서 커밋해도 저장소에는 NFC 이름이 기록됩니다. macOS용 Git은 저장소를 만들거나 클론할 때 이 값을 true로 설정하는 것이 기본 동작이지만, 오래전에 만든 저장소이거나 누군가 false로 바꿨거나, Git이 아닌 경로(압축 파일, 클라우드 동기화 폴더에서 복사)로 파일이 들어온 경우에는 NFD 이름이 저장소에 섞일 수 있습니다. 맥 사용자는 전역으로 명시해 두는 것이 안전합니다.

git config --global core.precomposeunicode true

이미 저장소에 NFD 이름이 들어갔다면, 맥이 아닌 환경(리눅스나 WSL)에서 이름을 NFC로 바꿔 커밋하는 것이 가장 확실합니다. 맥의 파일 시스템은 두 형태를 같은 이름으로 취급하므로 맥에서는 이 이름 변경을 제대로 하기가 어렵습니다. 우분투에서는 convmv 패키지로 정규화를 일괄 변환할 수 있습니다. --notest를 빼고 실행하면 실제로 바꾸지 않고 바꿀 목록만 보여 주므로 먼저 확인합니다.

sudo apt install convmv
convmv -f utf8 -t utf8 --nfc -r .            # 미리 보기
convmv -f utf8 -t utf8 --nfc -r --notest .   # 실제 변경
git add -A
git status   # renamed: 로 표시되는지 확인

git add -A는 삭제된 NFD 이름과 새로 생긴 NFC 이름을 함께 스테이징하므로, 내용이 같으면 Git이 이름 변경(rename)으로 인식합니다. 변경 후에는 팀원 모두가 새로 pull해야 하고, 맥 사용자는 위의 core.precomposeunicode 설정을 확인해야 같은 문제가 다시 생기지 않습니다.

diff 안의 한글만 깨질 때: CP949로 저장된 파일

파일 이름도 정상이고 커밋 메시지도 정상인데 git diff 결과의 본문 한글만 깨진다면, 그 파일 자체가 UTF-8이 아닌 CP949(또는 EUC-KR)로 저장되어 있는 것입니다. 오래된 윈도우 프로젝트의 소스 코드, 메모장에서 “ANSI”로 저장한 텍스트, 국내 시스템에서 내려받은 CSV 등에서 흔합니다. Git은 파일 내용을 바이트 그대로 저장하고, diff도 바이트 그대로 출력하므로 UTF-8 터미널에서는 깨져 보입니다.

CP949로 저장한 파일에 한 줄을 추가하고 git diff를 UTF-8로 읽은 실제 출력입니다(줄바꿈 변환 경고는 생략했습니다).

$ git diff
diff --git a/legacy.txt b/legacy.txt
index 267941d..b6996f3 100644
--- a/legacy.txt
+++ b/legacy.txt
@@ -1 +1,2 @@
 ù ��
+��° ��

원래 내용은 첫 줄과 둘째 줄입니다. “첫”의 CP949 바이트 C3 B9가 우연히 UTF-8로도 유효한 문자 ù가 되어 ù가 보이고, 나머지는 UTF-8로 해석할 수 없어 �로 나옵니다. 이렇게 라틴 문자와 �가 섞여 나오는 모양이 CP949 파일의 전형적인 증상입니다.

해결 방법은 세 가지이고, 상황에 따라 고릅니다.

첫째, 가장 근본적인 방법은 파일을 UTF-8로 변환해서 커밋하는 것입니다. 그 파일을 읽는 프로그램(컴파일러, 업무 시스템)이 UTF-8을 받아들일 수 있다면 이 방법이 이후 모든 문제를 없앱니다.

iconv -f cp949 -t utf-8 legacy.txt > legacy.utf8 && mv legacy.utf8 legacy.txt

둘째, 파일은 CP949로 유지해야 하지만 저장소 안에서는 UTF-8로 다루고 싶다면 .gitattributes의 working-tree-encoding 속성을 씁니다(Git 2.18 이상). 이 속성을 지정하면 Git은 커밋할 때 작업 폴더의 CP949 내용을 UTF-8로 변환해 저장하고, 체크아웃할 때 다시 CP949로 되돌려 놓습니다.

# .gitattributes
*.txt text working-tree-encoding=CP949

같은 실험을 이 속성을 넣은 새 저장소에서 반복한 실제 출력입니다. diff가 정상으로 나옵니다.

$ git diff
diff --git a/legacy.txt b/legacy.txt
index cd24cfd..b466950 100644
--- a/legacy.txt
+++ b/legacy.txt
@@ -1 +1,2 @@
 첫 줄
+둘째 줄

이어서 저장소 안의 내용(git cat-file -p HEAD:legacy.txt)과 작업 폴더의 파일을 바이트 단위로 읽어 비교해 보면, 저장소에는 UTF-8 바이트(EC B2 AB = “첫”)가, 작업 폴더에는 여전히 CP949 바이트(C3 B9 = “첫”)가 들어 있습니다. 아래는 그 바이트를 파이썬으로 출력한 결과입니다(작업 폴더 쪽은 한 줄을 추가한 뒤의 내용입니다).

blob bytes in repo: b'\xec\xb2\xab \xec\xa4\x84\n'
working tree bytes: b'\xc3\xb9 \xc1\xd9\n\xb5\xd1\xc2\xb0 \xc1\xd9\n'

편리하지만 주의할 점이 있습니다. Git 공식 문서도 꼭 필요할 때만 쓰라고 권하는데, 이유는 다음과 같습니다. 이 속성을 지원하지 않는 Git 구현이나 오래된 Git을 쓰는 도구에서는 저장소의 UTF-8 내용이 그대로 작업 폴더에 나와 버립니다. 또 이미 CP949 바이트로 커밋된 파일이 있는 저장소에 나중에 이 속성을 추가하면, 기존 커밋의 내용은 여전히 CP949 바이트이므로 저장소 안의 인코딩이 섞이게 됩니다. 기존 파일을 다시 UTF-8로 저장소에 넣으려면 속성을 추가한 뒤 해당 파일을 다시 스테이징해서 커밋해야 하는데, 이 과정 후에는 git show HEAD:legacy.txt가 UTF-8 터미널에서 정상으로 보이는지로 결과를 확인하는 것이 좋습니다.

셋째, 저장소와 파일은 그대로 두고 diff를 볼 때만 변환하고 싶다면 textconv를 씁니다. 저장되는 바이트는 바뀌지 않고, git diff와 git log -p의 표시만 바뀝니다. 다른 사람의 저장소에 영향을 주지 않고 내 컴퓨터에서만 읽기 편하게 만들 때 적합합니다.

# .gitattributes (또는 커밋하지 않으려면 .git/info/attributes)
*.txt diff=cp949

# 변환 명령 등록
git config diff.cp949.textconv "iconv -f cp949 -t utf-8"

Git Bash에는 iconv가 함께 설치되어 있으므로 윈도우에서도 같은 설정을 쓸 수 있습니다.

새 저장소에서 처음부터 막는 법과 설정을 되돌리는 법

이미 생긴 문제를 고치는 것보다 처음부터 섞이지 않게 하는 편이 훨씬 쉽습니다. 새 프로젝트를 시작한다면 저장소 루트에 .editorconfig를 두어 편집기가 UTF-8로 저장하도록 하고, 팀에 맥 사용자가 있다면 core.precomposeunicode 확인을 온보딩 문서에 넣어 두면 대부분의 문제를 예방할 수 있습니다.

# .editorconfig
root = true

[*]
charset = utf-8

이 글에서 바꾼 전역 설정은 모두 ~/.gitconfig(윈도우는 C:\Users\<사용자>\.gitconfig)에 기록됩니다. 되돌리고 싶다면 해당 항목을 지우면 기본값으로 돌아갑니다.

git config --global --unset core.quotepath
git config --global --unset core.precomposeunicode
git config --global --unset i18n.logOutputEncoding
git config --global --list --show-origin   # 남아 있는 설정과 위치 확인

--show-origin은 각 설정이 어느 파일에서 왔는지 보여 줍니다. Git for Windows는 설치 폴더의 시스템 설정 파일에도 기본값을 넣어 두기 때문에, 전역 설정을 지웠는데도 값이 남아 있다면 이 출력으로 출처를 확인할 수 있습니다. 저장소별 설정(.git/config)이 전역 설정보다 우선한다는 점도 기억해 두면, “다른 저장소에서는 되는데 이 저장소만 깨진다”는 상황을 빨리 풀 수 있습니다.

같이 보면 좋은 글

개발 환경 에러 응급처치표: 증상별 첫 확인