커밋할 변경 사항을 확인하기 위해 git status를 입력했는데, 다음과 같은 결과가 나왔다.
git을 잘 모르는 상태지만, 뭔가 빨간색이면 문제가 있다는 것이 느껴졌다..
우선, 이를 해결하기 위해 modified와 Untracked files가 무엇인지부터 알아보았다.
워킹 디렉토리의 모든 파일은 크게 Tracked, Untracked로 나눈다.
1. Tracked(관리대상임) : 이미 스냅샷에 포함돼 있던 파일, 즉 Git이 알고 있는 파일이다.
- Unmodified(수정하지 않음)
- Modified(수정함)
- Staged(커밋으로 저장소에 기록할 상태)
2. Untracked(관리대상이 아님) : 위 파일을 제외한 나머지 파일로,
워킹 디렉토리에 있는 파일 중 스냅샷에도 Staging Area에도 포함되지 않은 파일이다.
-> 처음 저장소를 Clone 하면 모든 파일은 Tracked면서 Unmodified 상태이다.
(파일을 Checkout하고 나서 아무것도 수정하지 않았기 때문이다.)
-> 마지막 커밋 이후 아무것도 수정하지 않은 상태에서 어떤 파일을 수정하면 Git은 그 파일을
Modified 상태로 인식한다.
앞부분의 빨간 부분은 modified와 Untracked files로 각각 수정한 파일, 관리대상이 아닌 파일이라고 말할 수 있겠다.
1. Modified
그럼, 첫 번째로 modified는 어떻게 해결해야 할까?
난 git add를 이용하여 해결했다.
git add는 파일을 커밋(commit)하기 전에 수정한(or 저장하고 싶은) 파일들을 Staged 상태로 만들 때 활용하는 명령어이다.
2. Untracked files
두 번째로, Untracked files도 똑같이 git add로 추가했다.
git add . 를 사용하면 워킹 디렉토리에 있는 파일중에서 변경된 모든 파일을 선택하지만, 난 불안해서
5개의 파일 혹은 폴더들을 하나씩 git add로 추가해줬다.
3. CRLF
그런데, 추가하던 중 다음과 같은 문구가 떴다.
warning: in the working copy of 'package.json', LF will be replaced by CRLF the next time Git touches it
문제의 이유는 다음과 같이 추측하고 있다.
Windows에서는 line 인코딩으로 CR과 LF를 사용한다.
Unix나 Mac OS는 LF만 사용한다.
-> fork 해온 파일을 만든 환경이 Mac OS고 나는 Windows 환경으로 사용해서 그런게 아닐까?
세 번째 문제는 git config core.autocrlf true로 해결하였다.
줄 끝을 처리하도록 Git 구성 - GitHub Docs
diff에서의 문제를 방지하기 위해 줄 끝을 제대로 처리하도록 Git을 구성할 수 있습니다.
docs.github.com
해결 방안으로는 두 가지가 있었으나,
git config -- global core.autocrlf true : 시스템 전체에 적용
git config core.autocrlf true : 해당 프로젝트에만 적용
시스템 전체에 적용하기엔 불안한 느낌이 있어 우선적으로 해당 프로젝트에만 적용해두었다.