전에도 깃허브를 사용해 보려고 깔짝 대다가 이번 기회에 한 번 제대로 해보자! 마음 먹고 문을 두드렸다.
( 지인과의 스터디로 약간의 강제성이 부여 되었다 )
GUI의 힘을 빌릴 수도 있지만 그래도 기왕이면 커맨드모드로 하고 싶었기에 처음 부터 하는 느낌으로 시작했다.
사용법에 대한 많은 사이트가 있는데 그 중에서 기본적인 명령어와 전체적인 흐름을 볼 수 있는 곳 말고, 명령어에 대해서 구체적인 언급이 되어 있는 곳은 찾기가 어려웠으며, 구체적인 언급이 있더라도 영어로 되어 있기에 내가 해석 해가며 실행해 보기란... 좀 난감한 부분이 있었다.
아무래도 기초적인 부분을 벗어나면 테스트 하다보니 점점 깊이 있는(?) 궁금증이 생기거나 실수로 로컬저장소를 통째로 날려버리기도 했는데, 아래와 같은... ( 참고로 reset 명령어를 사용할 때에는 적어도 --soft 옵션으로 사용하자 )
$ git reset --hard
구글링 중 'Pro Git'이라는 책을 번역한 사이트가 있었는데 2009년 출간한 첫번째 버전과 2014년 재출간한 두번째 버전까지 온라인 번역이 잘 되어 있... 아, 번역을 할 줄 몰라서 잘 되어 있는지 알 수는 없었다. 단지 좋았다.
구지 번역본을 볼 필요가 없다면 그냥 깃허브 설치 후 --help 명령어로 얼마든지 해석해서 살펴볼 수 있겠다.
$ git remote --help
같은... ( 영어공부.. 하.. )
그리고 기본적인 원사이클을 돌아보고 테스트로 메이븐 프로젝트를 생성하여 복습할 겸 커밋을 찍는데 오류가 발생했다.
$ git add .
warning: LF will be replaced by CRLF in pom.xml
The file will have its original line endings in your working directory.
이유는 윈도우 계열과 유닉스(맥, 리눅스) 계열에서의 서로 다른 플랫폼에서의 공유시 발생하는 소스의 줄바꿈 이었다.
설명에는 다음과 같았다.
협업할 때 겪는 소스 포맷(Formatting)과 공백 문제는 미묘하고 난해하다. 동료 사이에 사용하는 플랫폼이 다를 때는 특히 더 심하다. 다른 사람이 보내온 Patch는 공백 문자 패턴이 미묘하게 다를 확률이 높다. 편집기가 몰래 공백문자를 추가해 버릴 수도 있고 크로스-플랫폼 프로젝트에서 윈도 개발자가 줄 끝에 CR(Carriage-Return) 문자를 추가해 버렸을 수도 있다. Git에는 이 이슈를 돕는 몇 가지 설정이 있다.
core.autocrlf
윈도에서 개발하는 동료와 함께 일하면 줄 바꿈(New Line) 문자에 문제가 생긴다. 윈도는 줄 바꿈 문자로 CR(Carriage-Return)과 LF(Line Feed) 문자를 둘 다 사용하지만, Mac과 Linux는 LF 문자만 사용한다. 아무것도 아닌 것 같지만, 크로스 플랫폼 프로젝트에서는 꽤 성가신 문제다.
Git은 커밋할 때 자동으로 CRLF를 LF로 변환해주고 반대로 Checkout할 때 LF를 CRLF로 변환해 주는 기능이 있다. core.autocrlf 설정으로 이 기능을 켤 수 있다. 윈도에서 이 값을 true로 설정하면 Checkout할 때 LF 문자가 CRLR 문자로 변환된다:
$ git config --global core.autocrlf true
줄 바꿈 문자로 LF를 사용하는 Linux와 Mac에서는 Checkout할 때 Git이 LF를 CRLF로 변환할 필요가 없다. 게다가 우연히 CRLF가 들어간 파일이 저장소에 들어 있어도 Git이 알아서 고쳐주면 좋을 것이다. core.autocrlf 값을 input으로 설정하면 커밋할 때만 CRLF를 LF로 변환한다:
$ git config --global core.autocrlf input
이 설정을 이용하면 윈도에서는 CRLF를 사용하고 Mac, Linux, 저장소에서는 LF를 사용할 수 있다.
윈도 플랫폼에서만 개발하면 이 기능이 필요 없다. 이 옵션을 false라고 설정하면 이 기능이 꺼지고 CR 문자도 저장소에도 저장된다:
$ git config --global core.autocrlf false
core.whitespace
Git에는 공백 문자를 다루는 방법으로 네 가지가 미리 정의돼 있다. 두 가지는 기본적으로 켜져 있지만 끌 수 있고 나머지 두 가지는 꺼져 있지만 켤 수 있다.
먼저 기본적으로 켜져 있는 것을 살펴보자. trailing-space는 각 줄 끝에 공백이 있는지 찾고 space-before-tab은 모든 줄 처음에 tab보다 공백이 먼저 나오는지 찾는다.
기본적으로 꺼져 있는 나머지 두 개는 indent-with-non-tab과 cr-at-eol이다. intent-with-non-tab은 tab이 아니라 공백 8자 이상으로 시작하는 줄이 있는지 찾고 cr-at-eol은 줄 끝에 CR 문자가 있어도 괜찮다고 Git에 알리는 것이다.
core.whitespace 옵션으로 이 네 가지 방법을 켜고 끌 수 있다. 설정에서 해당 옵션을 빼버리거나 이름이 -로 시작하면 기능이 꺼진다. 예를 들어, 다른 건 다 켜고 cr-at-eol 옵션만 끄려면 아래와 같이 설정한다:
$ git config --global core.whitespace \
trailing-space,space-before-tab,indent-with-non-tab
git diff 명령을 실행하면 Git은 이 설정에 따라 검사해서 컬러로 표시해준다. 그래서 좀 더 쉽게 검토해서 커밋할 수 있다. git apply 명령으로 Patch를 적용할 때도 이 설정을 이용할 수 있다. 아래처럼 명령어를 실행하면 해당 Patch가 공백문자 정책에 들어맞는지 확인할 수 있다:
$ git apply --whitespace=warn <patch>
아니면 Git이 자동으로 고치도록 할 수 있다:
$ git apply --whitespace=fix <patch>
이 옵션은 git rebase 명령에서도 사용할 수 있다. 공백 문제가 있는 커밋을 서버로 Push하기 전에 --whitespace=fix 옵션을 주고 Rebase하면 Git은 다시 Patch를 적용하면서 공백을 설정한 대로 고친다.
참조 : 소스-포맷과-공백
그래서 여러 플랫폼을 대비하여 core.autocrlf 옵션을 input 으로 주었다.
그리고 커밋을 해보니 각 파일마다 문제가 되는 라인의 문자에 대한 replace 를 실행하며 진행한 로그를 확인할 수 있었다.
$ git commit -m 'test commit' //커밋
...
warning: CRLF will be replaced by LF in .project.
The file will have its original line endings in your working directory.
...(반복)
17 files changed, 490 insertions(+)
create mod 100644 .project
...(반복)
$ git status //상태확인
On branch master
nothing to commit, working directory clean
* Git 설치시 옵션을 해석할 수 있는 사용자라면...
윈도우에서 설치 진행시 2번째 옵션을 선택하는 단계에서 Checkout as-is, commit Unix-style line endings 를 선택했다면 이런 수순을 밟지 않아도 된다. 뭐.. 오히려 기본으로 다음, 다음, 다음 해가며 설치했기에 이런 부분도 알 수 있지 않았나 싶다.