Git command : add (feat.crlf)

add : file 변경사항 추가하기 (feat. crlf)

>>> git add file name
>>> git add *.txt

 add는 추가한다는 의미의 단어로, 변경 사항들을 stage에 추가하는 명령어이다. 명령어를 사용하게 되면 아직 commit이 없으나 commit할 수 있는 변경 사항이 존재한다는 내용을 볼 수 있다. 그리고 이렇게 stage에 올라간 파일들을 commit 하게 된다. status 명령어는 바로 다음 내용으로 정리할 예정이다.

 혹시라도 추가하면 안될 파일을 추가했다면 어떨까?? 당황하지 않아도 된다. 방금 위의 이미지에서 status 명령어를 친 다음 볼 수 있는 메시지를 확인하고 다음 이미지로 가보자.

 

>>> git rm --cached "file name"

 add 명령어를 사용하고 난 후 status 명령어를 이용해서 현재 상태를 확인해보면 rm 명령어를 사용해서 stage에 올라간 원하지 않는 파일을 unstage할 수 있다고 친절하게 메시지로 나타내주기 때문에 전혀 당황하지 않아도 된다. 이 명령어를 통해 원하지 않는 파일을 staging area에서 working directory로 다시 옮길 수 있다.

 

>>> git restore --staged "file name"

 주의할 점은 이미 tracking 되고 있는 파일을 add로 추가했다가 이 명령어를 작성한다면 다시 untracking 된다는 것이다. 이런 경우 unstage 하고 싶다면 restore 명령어를 사용한다.

 

 이 단계에서의 문제는 이미지 상단의 add 명령어를 사용한 직후에 등장하는 경고문구이다. 경고문의 LF와 CRLF가 무엇인지와 관련 설정, 또 이에 대한 자체적인 실험과 고찰이 있어서 가져오겠다.

---

 

>>> git config --global core.autocrlf true		### windows user

>>> git config --global core.autocrlf input		### mac user

 windows 사용자라면 true로, mac 사용자라면 input으로 해당 코드를 작성해준다. 굉장히 중요한 작업이다. 이유는 다음과 같다.

 

 운영체제마다 editor에서 새로운 줄바꿈을 할 때 들어가는 문자열이 달라진다. Windows의 경우는 carriage-return(\r)(CR)과 line feed(\n)(LF)가 동시에 들어가는데, Mac에서는 line feed(\n) 하나만 들어간다. 이런 차이점 때문에 Git repository를 다양한 운영체제에서 쓰는 경우에, 본인이 수정하지 않았음에도 불구하고 줄바꿈 문자열이 달라지는 점 때문에 Git history나 Git blame을 보는데에 문제가 발생할 수 있다. 이것을 수정할 수 있는 설정이 'autocrlf'이다.

 

 Windows에서 true로 설정하게 되면 Git에서 저장할 때는 carriage-return을 삭제하게 되고, 다시 Git에서 윈도우로 가져올때는 자동으로 carriage-return을 붙여준다. 반면에 Mac에서는 input으로 설정하게되면 Git에서 받아올때는 별다른 수정이 일어나지 않지만, 저장할 때는 carriage-return을 삭제해준다.

 그런데 이상하지 않은가? Windows고 Mac이고 Git에 애초에 carriage-return을 삭제하여 저장하는 것이라면 Mac 입장에서는 별다른 설정을 하지 않아도 되는 부분이지 않아도 된다. 하지만 이렇게 처리해주는 이유는 Mac에서 이메일을 받아온 text를 복사해서 붙여넣을 때, 실수로 carriage-return이 들어갈 수 있기 때문이라고 한다. 이럴 때는 carriage-return을 없애야한다. 그래서 Windows라면 true로, Mac이라면 input으로 설정하는 것이 좋다.

 

 

 상단의 오류는 crlf 설정을 해주지 않았기 때문이다. 혹시라도 보인다면 autocrlf 설정을 Windows라면 true로, Mac이라면 input으로 해주자. 

 변경했음에도 필자는 계속해서 해당 메시지를 볼 수 있었다. 그래서 간단한 실험에 돌입했다. 실험은 간단했다. git bash에서 새로 파일을 만들어 진행하는 것과, cmder에서 새로 파일을 만들어 진행하는 것을 비교하는 것이다.

1. git bash에서 만들어서 git bash에서 add 하기.
2. git bash에서 만들어서 cmder에서 add 하기.
3. cmder에서 만들어서 git bash에서 add 하기.
4. cmder에서 만들어서 cmder에서 add 하기.

 결과는 심플했다. git bash에서 만들어서 git add 명령어로 staging area로 옮길 때만 오류 메시지를 확인할 수 있었고, cmder에서 만든 파일들에서는 오류메시지를 확인할 수 없었다. 즉, git bash에서 만든 파일들은 linux에서 만든 파일처럼 취급한다는 것이라는 결론이다. Windows에서 bash 환경을 여는 것인데, Mac에서의 기본 terminal이 bash인 점을 감안한다면 문제가 발생하는 것이 맞는 것 같다. 주의한다.

---

 

 

>>> git add .

 만약 세 파일을 모두 staging area로 옮겼을 때 d라는 파일이 삭제되면, working directory에 d.txt 가 삭제되었다는 메시지를 볼 수 있다. 물론 메시지가 권장하는대로 d.txt를 add 하거나 rm으로 지워주거나, restore 명령어로 stage에 올라간 d.txt를 없애도 된다. 여기서 삭제된 파일을 add하는 경우, git status를 확인해보면 삭제된 d 파일은 directory에 없었기 때문에 staging area에 추가되지 않은 것을 확인해볼 수 있다. 즉, 삭제되었지만 삭제된 파일이 존재하지 않아서 삭제된 파일의 staging이 일어나지 않는 것이다.

 이 방법들 말고도 git add .를 작성하게 되면 현재 Git으로 관리하고 있는 모든 파일을 포함해서 staging area에 추가한다고 한다. 즉, 파일을 삭제한 내용을 add 하게되는 결과이기 때문에 해당 파일은 staging area에서 사라지게 되는 것이다. 이 git add . 은 git add * 과 같은 결과를 낸다고 생각하면 편하다.

 

 검색을 통해 알아본 바로는 *을 사용한 add는 .gitignore에 명시된 내용들과 상관없이 모든 파일에 대한 작업을 수행하지만, .을 사용한 add는 .gitignore에 명시된 친구들을 제외한 모든 파일에 대해 작업을 수행한다고 한다. 하지만 log 확장자 파일을 제외하는 .gitignore 파일을 만들어 수행해본 결과 두 방식의 결과는 같았다.

 

 .gitignore는 다음 status 명령어 다음에 다뤄보기로 한다.