Git status에서 모든 파일이 modified로 뜰 때 — WSL에서 만난 CRLF/LF 문제

배포를 준비하면서 Windows에서 작업하던 프로젝트를 WSL Ubuntu에서 열었다.

평소처럼 프로젝트 폴더로 이동하고 git status를 입력했다.

git status

 

그런데 결과를 보고 순간 당황했다.

내가 수정한 기억이 없는 파일들이 전부 modified로 표시되고 있었다.

Java 파일부터 Gradle 설정 파일, 문서 파일까지 거의 프로젝트 전체가 수정된 것처럼 보였다.

처음 든 생각은 단순했다.

배포 준비하다가 프로젝트를 잘못 건드렸나?

---

내가 수정한 파일이 이렇게 많을 리가 없었다

당시 내가 실제로 추가한 건 배포를 위한 설정 몇 개뿐이었다.

그런데 Git에서는 이런 식으로 수많은 파일이 변경됐다고 나왔다.

modified:   build.gradle
modified:   settings.gradle
modified:   src/main/java/...
modified:   docs/...
...

 

처음에는 꽤 식겁했다.

이미 개발은 거의 끝난 상태였고 배포만 남겨둔 상황이었다.

여기서 파일 수십 개가 실제로 변경된 거라면 다시 확인해야 할 범위가 너무 컸다.

그래서 일단 코드를 되돌리기 전에 정말 내용이 바뀐 건지부터 확인하기로 했다.

---

실제 변경 내용을 다시 확인해봤다

Git에는 줄바꿈 차이를 무시하고 변경 내용을 확인하는 옵션이 있다.

 

git diff --ignore-space-at-eol --stat

 

실행해보니 결과가 완전히 달랐다.

.dockerignore | 7 +++++++
railway.toml  | 6 ++++++
2 files changed, 13 insertions(+)

 

실제로 내가 수정한 파일은 거의 이것뿐이었다.

그제야 안심했다.

그리고 원인을 찾아보니 Windows와 Linux의 줄바꿈 방식 차이 때문이었다.

---

CRLF와 LF가 뭐길래 파일 전체가 바뀐 걸까

Windows와 Linux는 줄바꿈을 표현하는 방식이 조금 다르다.

Windows에서는 일반적으로

CRLF

 

Linux에서는

LF

 

를 사용한다.

개발자가 코드를 볼 때는 둘 다 그냥 다음 줄로 넘어간 것처럼 보인다.

그래서 평소에는 거의 신경 쓰지 않는다.

그런데 Git 입장에서는 이야기가 다르다.

줄 끝에 들어가는 문자가 달라지면 Git은 그것도 변경으로 판단할 수 있다.

내 프로젝트는 Windows에서 작업하던 프로젝트였고, 그걸 WSL Ubuntu에서 열었다.

환경이 Windows에서 Linux로 바뀌면서 줄바꿈이 다르게 인식됐고, 결과적으로 Git에서는 파일 전체가 수정된 것처럼 보였던 것이다.

---

git status만 보고 바로 되돌렸다면?

이때 조금 위험했던 게 있다.

git status만 보고

이상하게 바뀌었네. 전부 되돌려야겠다.

라고 생각했다면 내가 실제로 추가한 배포 설정까지 같이 날릴 수도 있었다.

그래서 이번에 느낀 건 간단했다.

Git에서 예상하지 못한 변경이 보이면 일단 내용을 확인하는 게 먼저다.

예를 들어 이런 명령어들이 도움이 된다.

 

git diff

 

파일별 변경 내용을 확인할 수 있다.

줄바꿈 때문에 보기 어려운 경우에는

 

git diff --ignore-space-at-eol

 

처럼 줄 끝의 공백 차이를 무시하고 볼 수도 있다.

전체 변경 규모만 보고 싶다면 내가 사용했던 것처럼

 

git diff --ignore-space-at-eol --stat

 

도 꽤 유용했다.

나는 이걸 실행하고 나서야

“아, 코드가 전부 바뀐 게 아니구나.”

라는 걸 확인할 수 있었다.

---

Windows와 WSL을 같이 쓰면 한 번쯤 만날 수 있는 문제

나는 Windows에서 IntelliJ로 개발하고 있었다.

그러다가 Docker와 배포 환경을 준비하면서 WSL Ubuntu까지 사용하게 됐다.

같은 프로젝트인데도 어느 환경에서 파일을 열고 저장하느냐에 따라 줄바꿈 문제가 생길 수 있었다.

특히 이런 상황이라면 한 번 의심해볼 만하다.

Windows에서 개발하던 프로젝트를 WSL에서 열었다.
↓
코드는 거의 건드리지 않았다.
↓
git status를 실행했다.
↓
갑자기 수십 개 파일이 modified로 표시된다.

 

이 상황이라면 진짜 코드가 바뀐 건지 확인하기 전에 CRLF/LF 문제부터 보는 게 좋다.

---

그럼 어떻게 예방할까?

프로젝트에서 줄바꿈 규칙을 명확하게 정해두면 이런 문제를 줄일 수 있다.

대표적으로 .gitattributes를 사용할 수 있다.

예를 들면 이런 식이다.

* text=auto

 

조금 더 명확하게 LF를 사용하도록 정할 수도 있다.

* text=auto eol=lf

 

다만 이미 여러 사람이 작업하는 프로젝트라면 갑자기 줄바꿈 규칙을 바꾸기 전에 기존 설정을 확인하는 게 좋다.

설정 하나 바꿨다가 정말로 파일 전체가 변경되는 경우도 있기 때문이다.

Git의 core.autocrlf 설정도 확인할 수 있다.

 

git config --get core.autocrlf

 

Windows와 Linux를 같이 사용하는 환경이라면 한 번쯤 확인해둘 만하다.

---

이번에는 아무것도 망가지지 않았다

배포하려고 Linux 환경으로 넘어갔다가 갑자기 프로젝트 전체가 수정된 것처럼 보여서 잠깐 긴장했다.

결론적으로 실제 코드는 거의 바뀌지 않았다.

문제는 Windows와 Linux의 줄바꿈 차이였다.

이번 일을 겪고 나서 git status 결과를 조금 다르게 보게 됐다.

modified라고 적혀 있다고 해서 무조건 내가 코드를 수정했다는 뜻은 아니었다.

중요한 건

무엇이 달라졌는지 확인하는 것.

앞으로 또 프로젝트 전체가 갑자기 빨간색으로 변해 있더라도 이번보다는 덜 놀랄 것 같다.

아마도.

---

이번에 사용한 명령어

 

git status

 

현재 변경 파일 확인.

 

git diff

 

실제 변경 내용 확인.

 

git diff --ignore-space-at-eol --stat

 

줄 끝 차이를 무시하고 실제 변경 규모 확인.

 

git config --get core.autocrlf

 

Git 줄바꿈 관련 설정 확인.

---

한 줄 정리

Windows 프로젝트를 WSL에서 열었는데 Git에서 모든 파일이 modified로 나온다면, 코드를 되돌리기 전에 CRLF/LF 줄바꿈 차이부터 확인해보자.