머가필요해

또 다시 간만에 작성하는 Git 이야기...^^

branch의 경우 설명하는 글들을 읽어도 알기 힘든 부분들이 많다.



오늘 살펴보고자 하는 것은 지난 번 포스팅한 내용 중,
merge를 하게 되면 마지막 commit을 한 내용을 그대로 가져온다고 했었다는 내용에 대해서다.


Git의 branch를 그냥 막 사용한다면 모르겠지만,
하나 하나 그 내용을 분석이 필요하다고 하면 아래 내용을 잘 따라와보면 도움이 될 것이다.



1. 준비

   - 지금 branch를 활용한 작업을 하기 전에 준비를 하자.

$ git branch -a

   - [ git branch -a ] 명령을 통해 모든 branch 상태에 대해서 알아보자.
   - [ * ] 표시가 되어있는 branch가 지금 현재 작업을 하고 있는 branch이다.


2. branch & commit

   - branch를 하나 만들고, 'master branch'에서 commit을 하나 해보자. 

$ git branch patch1  $ nano ./readme.txt  $ git commit -a -m "nano readme.txt in master br"

   - "A" 시점에서 'patch1 branch'를 생성을 하고,
   - 'master branch'에서 파일 수정 후 commit을 해서 "B" 시점으로 갔다.
   - 그래서 'master branch'는 지금 현재 "B" 위치에 있는 것이다.


3. checkout & commit

   - 작업하고 있는 branch를 바꿔보자.

$ git checkout patch1

   - [ git checkout patch1 ]을 통해 작업하고 있는 branch를 변경했다.

$ nano ./readme1.txt  $ git commit -a -m "nano readme1.txt in patch1 br"

   - 'readme1.txt' 파일을 수정 후 commit 하자.

   - commit을 추가로 한 번 더 해보자.

$ nano ./readme1.txt  $ git commit -a -m "1 more, nano readme1.txt in patch1 br"

   - 'patch1 branch'에서 commit 2건을 추가한 것이다.



4. checkout & merge

   - 각 branch 別 상황을 좀 살펴보자.

$ git branch -a  $ git log -2  $ git checkout master  $ git log -2

   - 'patch1 branch'의 log들과 'master branch'의 log들을 잘 살펴보기 바란다.

   - 이제 merge를 실행해 보자.

$ git merge patch1  $ git log -4

   - 위 그림과 스크린샷을 잘 봐야 한다!!! 많은 것들이 녹아 있다.

   - "E" 지점(commit)은 별도로 만든 것이 아니라 'merge'로 만들어진 것이다.
   - 그래서 log를 보면 "Merge branch 'patch1'"이 보일 것이다.

   - 그런데, 또 하나 특이한 것은 'patch1'에서 이루어진 commit까지 모두 따라왔다.
   - 그러면, 'patch1 branch'를 지워버리면 어떻게 될까?

$ git branch -d patch1

   - 'patch1 branch'를 그냥 지워버리면 어떻게 될까?!
   - 위에서 보는 바와 같이 그냥 'branch'만 지워지고 변화는 없다.


   - branch를 지운다고 하여도 그 branch에서 작업을 했던 commit들은 지워지지 않는다는 말 같은데...
   - merge가 되었다면 의미가 있지만, merge가 없는 상태에서 branch를 지웠다면...
   - 의미 없는 commit들이 그냥 살아있다는 말이 되는데...
   - 이 부분에 대해서는 꼭 한 번 깊이있게 살펴볼 예정이다. 개인적으로 관심있는 부분이라서....^^



여하튼, 이번 포스팅에서 확인을 한 것은,
branch에서 만든 commit들이 merge 후에도 계속 따라온다는 것이다.

commit 하나 하나에 더욱 더 신경을 써야 한다는 결론이 나온다.

Git Branch에 대해서 계속 살펴보자.


1. git checkout -b

$ git checkout -b hotfix

   - 브랜치를 만들고 새로 만든 브랜치로 작업 영역을 변경하기 위해서는 2단계의 과정을 거쳐야 한다.
      . [ git branch 블라블라 ] + [ git checkout 블라블라 ]

   - 이걸 한 묶음으로 처리하기 위해서는 아래와 같이 하면 된다.
      . [ git checkout -b 블라블라 ]


2. commit

   - 현재 어느 브랜치에서 작업을 하고 있는지 확인을 하고... [ git branch ]
   - 파일을 하나 수정 후 commit을 하자. [ git commit -a -m "블라블라" ]

   - 지금 긴급히 수정할 꺼리가 있어서 hotfix를 한다고 가정을 해보는 것이다.


3. merge

$ git branch  $ git checkout master  $ git merge hotfix

   - 변경 사항을 가지고 올 브랜치로 checkout을 먼저 하고선, [ git checkout master ]
   - 어느 브랜치의 것을 가지고 와서 merge를 할지 명령을 하면 된다. [ git merge hotfix ]

   - 여기서 궁금한 것은 merge를 한 것은 알겠는데, 파일만 합친 것인지...?!

   - merge를 한 이후 [ git log ]를 해보면, 본래 없던 commit이 추가되어 있는 것이 보일 것이다.
   - 즉, 위의 경우는 "hotfix" 브랜치의 마지막 commit을 "master" 브랜치로 복사해버린 것이다.



4. delete

$ git branch -d hotfix

   - 용도가 없는 branch를 지울 때엔 '-d' 옵션을 이용하면 된다.




브랜치에 대해서 공부를 하려면 꼭 나타나는 '머지 (merge)'다.
일단 가볍게 맛만 보는 정도에서 마무리 짓겠다.


앞으로도 몇 번 더 포스팅하면서 더 알아보도록 하겠다.

최근(?) 형상관리 도구에서 가장 중요한 기능 중의 하나가 바로 "브랜치 (branch)"이다.

개발 과정에서 '브랜치'를 활용하여 다양한 프로세스를 적용하게 되는데,
상당수의 형상관리 도구에서 '브랜치'를 사용하기 위해서는 많은 비용이 소요되곤 한다.

반면, Git의 특징 또는 장점으로 종종 언급되는 것이 바로 비교적 쉽고, 가볍게 '브랜치'를 사용할 수 있다는 것이다.

그러면, 이제 그 '브랜치'에 대해서 알아보아야 하는데,
많은 참고 자료들을 보면 좀 어렵게 설명이 되어 있어서 그 본질을 꽤뚫어보기가 쉽지는 않다.

하지만, 우리 사랑하는 "Git"에 대해서 알기 위해서는 꼭 넘어가야만 하는 산이기에,
차근차근 하나씩 알아나가보자.


1. branch 만들기, 현황 확인하기

$ git branch  $ git branch anotherbr

현재 repository의 branch 현황을 확인 하기 위해서는 [ git branch ]라고만 하면 된다.

repository를 생성하고 사용하게 되면, 기본적으로 git이 만들어주는 branch가 바로 "master"이다.
즉, branch 관련한 아무런 작업을 하지 않았다면, 그냥 'master' 브랜치에서 작업을 하고 있는 것이다.

그리고 위 스크린샷에서 보는 바와 같이, 현재 작업하고 있는 branch를 알려주는 표시는 "*"이다.


그러면, 새로 branch는 어떻게 만들까? [ git branch 블라블라 ]와 같이 하면 된다!

생성한 이후 [ git branch ]를 통해서 현황을 보면 위와 같이 나타날 것이다.



2. 일단 나는 master

$ git branch  $ nano ./readme.txt  $ git add ./readme.txt  $ git commit -m "modify readme.txt"  $ git push

repository에 있는 파일 하나를 수정하여 커밋하고, push를 해보자.
위 스크린샷을 보면 현재 어떤 branch에서 작업을 한 것인지 보일 것이다.



3. 나는 지금 어디에?

$ git branch  $ git checkout anotherbr

현재 작업하고 있는 branch를 변경하는 명령어는 [ git checkout 블라블라 ]이다.

위 스크린샷에서 보는 바와 같이 변경 후 [ git branch ]를 해보면 "*"가 변경되어 있는 것이 보일 것이다.

더불어서 좀 전에 'master branch'에서 작업한 파일을 확인해 보면... 뭔가 다른 것을 확인할 수 있을 것이다.



4. HEAD

현재 작업하고 있는 branch를 가리키는 포인터의 이름은 "HEAD"이다.

위의 작업들을 한 번 다시 곱씹어보자.

아무런 작업도 하지 않은 현재의 상태를 보면, C까지 작업을 한 상황에서 현재 사용중은 branch는 'master'다.
물론 당연히 'HEAD'는 'master'를 가리키고 있다.

[ git branch anotherbr ]를 이용해서 branch를 새로 만들었을 경우는 위와 같다.
똑같은 곳을 'master'와 'anotherbr'이 가리키고 있지만, 'HEAD'는 여전히 'master'를 가리키고 있다.

파일 수정작업을 하고 commit을 하였다면, 'master'는 추가로 작업한 모습을 새로 가리키고 되고
현재 작업하고 있는 branch를 가리키는 HEAD는 'master'를 가리키고 있다.

좀 전에 만든 'anotherbr' 브랜치는 여전히 좀 전과 같은 곳을 가리키고 있다.

[ git checkout anotherbr ] 명령어를 쳐서 작업 브랜치를 변경하겠다라고 하면,
'HEAD'는 이제 'anotherbr' 브랜치를 가리키게 된다.

직전에 변경한 파일 내역은 'master' 브랜치에서 이루어진 작업이므로 'anotherbr' 브랜치는 모르는 일이다.





오늘은 일단 여기까지 하고,
branch에 대해서 한 동안 계속 알아나가 보도록 하자~!!

Git을 공부하게 되면 다들 만나게 되는 감사한 책!  Pro Git

   - http://progit.org/

책 내용을 무료로 제공해주고 있다.
거기에다가 Git의 업데이트에 따라 내용 업데이트도 비교적 빠르게 반영이 된다.


몇 몇 아름다운 분들이 번역을 일부 진행하셨었다.

   - http://www.aesop.or.kr/Board_Documents_Linux_Applications/35568



그러던 중 최근 또 아름다운 분들이 이번에는 완벽히 번역을 마무리를 지어서 화제가 되고 있다.

   - https://github.com/dogfeet/progit


Github를 이용하여 공동 번역 작업을 해서 더욱 더 아름답다.
번역 작업을 하면서 사용한 Work-flow도 공개를 했다.

   - http://dogfeet.github.com/articles/2012/git-translate-flow.html 



그래서 조금 더 관련된 자료를 찾아보던 중 Git과 관련한 좋은 자료들을 조금 더 찾아보았다.

Git에 대해서 가르치는 선생님용 자료
   - http://cbx33.github.com/gitt/index.html 

Git 구조(?)를 보기 좋게 설명해준 자료
   - http://marklodato.github.com/visual-git-guide/index-ko.html 

세입자의 설움으로 전셋집 옮기고 체력고갈,
더불어 진급자 회식 및 결혼 예비 후배들과의 회식들로 인한 추가 체력고갈...
그리고 마지막으로 안또라이들 학습.... 그리고 결정적인 귀차니즘으로 또 다시 오랜만에 찾아온 Git... ^^

조금 더 공부하고 조금 더 분석해야하는데, 그게 말처럼 쉽지가 않다.... 월급쟁이의 비애라고하면 변명이겠지!? ^^


오늘은 remote repository에 대해서 조금 더 알아보고자 한다.

$ git clone /srv/repository/BareRepo.git $ cd ./BareRepo $ git remote $ git remote -v

[ git remote ]라는 명령어는 어떨 때 사용하는걸까!?
어떤 repository의 어떤 branch를 사용하고 있는지 알기 위해서 또는 관리를 위해서 사용하는 명령어이다.

만약 여러 repository를 사용할 경우 그 리스트도 주르륵 보여준다.


여기에서 당연히 의문을 가져야 한다!!!
"여러 repository를 사용"한다고?!

 

$ git remote add other /srv/repository/otherRepo.git $ git remote $ git remote -v

이미 "BareRepo.git"을 가져온 상태에서, 그 안에서 [ git remote add ]를 통해서 다른 repository를 가져온 것이다.
'other'라는 것은 임의로 해당 repository를 지칭하는 별명을 지어준 것이다.

본래 있던 것은 'original'이라는 이름이고, 새로 추가한 것은 'other'라는 이름이다.


그러면, 여기에서 또 하나의 의문이 생겨야 한다.

하나의 공간에 2가지의 것이 같이 있으면, 지금 작업하고 있는 것이 어떤 것에 속하는지 어떻게 알려줄까?

$ git fetch other

아직 branch에 대해서 알아보지 않았으므로 이에 대한 설명은 뒤로 넘기겠다.

여하튼, [ git fetch ]라는 명령어를 이용하여 두 가지를 오락가락 할 수 있다!
그런데, 지금 "otherRepo.git"이라는 repository를 넣었다고 했는데 그 파일들은 어디에 있을까?!

지금 사용하고 있는 "otherRepo.git" repository에 들어있는 파일은 "readme.txt"이다.
그런데, "BareRepo.git" repository에도 같은 이름의 파일이 있다.
"혹시 그래서 뭔가 충돌이 난 것은 아닐까?!"라는 생각이 들었다.

그래서, 응급으로 "otherRepo.git"에 "other.txt" 파일을 push해 넣었다.
그런 후 다시 fetch를 해보았다.

다시 fetch를 했음에도 파일 내용은 바뀐 것이 없다.


이 즈음해서 아! 내가 변경 사항을 받아오는 것에 대해서 살펴보지 않았구나~!!!라는 생각이 번뜩!
그래서 바로 직전 글 [ git pull ]에 대해서 블로깅을 했다!!!!

$ git pull $ git pull other master

그냥 [ git pull ]을 하게 되면 뭔가 받아오는데, 우리가 새로 추가한 repository, otherRepo의 자료는 보이질 않는다.
그러면 어떻게 해야 otherRepo의 내용을 받아올 수 있을까?!

[ git pull other master ]라고 하면 된다.
그런데, 위의 스크린샷을 보면 알겠지만 'CONFLICT'가 발생을 했다.

앞에서도 말했지만, 두 개의 repository에 'readme.txt' 파일이 똑같은 이름으로 존재하고있다.
그래서 충돌이 난 것이다.
보통은 git이 똑똑하게 자동으로 merge를 해주기도 하는데, 위의 경우엔 그것도 실패한 경우이다.



이번 블로그에서는 뭘 배우는 것이 아니라,
앞으로 무엇을 봐야할 지에 대해서 확인하고자 하는 블로깅이다.

[ git pull other master ]라는 명령어에서 'master'라는 것이 무엇인고 하니, 바로 branch 이름이다.
앞으로 branch에 대해서 살펴보도록 하겠다.

그 다음엔 위의 경우처럼 merge를 하는 경우에 대한 것이다.
repository를 여러개를 사용할 경우도 있지만, 주로 서로 다른 branch에서 하나로 merge하는 경우가 더 많을 것이다.


앞으로 하나씩 더 알아가 보도록 하자.

앞에서 먼저 설명을 했었어야 했는데,
아무 생각없이 건너뛴 부분이 생각나서 급하게 블로깅을 한다.


우선 기존의 repository들이 정리가 안된 느낌이라서 이번에 새로 repository를 생성해보겠다.

$ mkdir ./bare1repo.git $ cd ./bare1repo.git $ git --bare init

이제는 생성한 repository를 clone하여 보자.

$ git clone chani@localhost:/srv/repository/bare1repo.git $ cd ./bare1repo.git $ git status

잘 clone 받아온 것을 확인할 수 있다.

지금은 파일이 하나도 없으니, 일단 파일 하나를 추가하고 commit 해보자.

$ nano ./readme.txt $ git add ./readme.txt $ git commit -m "create readme.txt"

Remote repository로 변경 사항을 보내보자.

$ git status $ git push

보내기 위해서 'git push'를 했는데,
error가 발생을 했다.

push를 하기 위해서는 git에게 어떠한 방식으로 push를 할 것인지에 대해서 꼭 알려줘야 한다.
이전에도 한 번 언급을 했지만, 여기에서 다시 한 번 해보자.

$ git config push.default tracking $ git push

이번에는 잘 되었다!


테스트를 위해서 clone을 하나 더 해보자.

$ mkdir 2nd $ cd ./2nd $ git clone chani@localhost:/srv/repository/bare1repo.git

여기 repository에서 파일 하나를 더 추가해보자.

$ nano ./readme1.txt $ git add ./readme1.txt $ git commit -m "create readme1.txt" $ git push

여기에서 새로운 내용을 Remote repository에 넣었으나
이전에 내려 받은 repository에는 당연히 새로 변경된 내용이 반영이 되지 않았다.

그러면 이전에 내려 받은 repository에서 내용을 업데이트 하기 위해서는 어떻게 해야할까?

$ git pull

위 스크린샷을 보면 알겠지만 'git pull'을 하면 만사 OK다.

흐름을 살펴보면 아래와 같다.

여기에서는 바로 'git pull' 하나만 언급하지만, 실제로는 여러가지 작업이 복합되어 있다.

'git fetch'를 통해서 변경 사항을 내려받고, 지금 작업하고 있는 내용에 merge를 하는 과정을
한 방에 처리해주는 것이 바로 'git pull'이다.


나중에 'branch'와 'merge'에 대해서 학습을 하고선 다시 한 번 이 부분을 분석해보도록 하자!!!

앞에서 Git Server 를 두고 그곳에서 소스를 받아오고 작업한 내용을 넣는 것을 살짝 살펴보았다.


Git을 소개할 때 항상 나오는 "분산 관리", 그에 따라 나오는 이야기는 바로 "복제"이다.
무슨 말인고 하니, 서버와 클라이언트 모두 똑같은 데이터를 가진다는 점을 특징으로 한다고 한다!

기존의 서버-클라이언트 구조인 Subversion 등과는 달리,
Git은 서버와 클라이언트 개념이 없이 모두 같은 데이터를 가지고 동등한 입장이라고들 말한다.

하지만, 이 이야기로 인하여 Git에 대한 많은 오해가 있고, 또 괜히 어려워 하게 되는 것 같다.


분산 관리 도구인 Git이지만,
형상관리 도구의 특성상 분명히 기본적인 구조는 "서버-클라이언트"이다.

즉, 최종적인 결과물을 저장하는 서버의 역할을 하는 repository는 분명히 존재한다.
그 외 clone을 받아간 repository는 모두 클라이언트 이다.

clone을 -bare 형식으로 하여 Server 역할을 할 수 있는 repository를 만들었더라도
전체 구조에서는 어디까지나 클라이언트의 역할이다.

말 장난같이 들릴지 모르겠지만, 위의 사항에 대해서는 잘 이해를 하였으면 좋겠다.

전체적인 흐름은 위와 같다.

   - Remote repository에서 'git clone'을 통해 소스를 받아오고
   - 소스 수정 작업을 한 뒤에
   - 'git add'를 통해 staged 상태로 만든 뒤
   - 'git commit'을 하고나서
   - 변경 사항을 'git push'를 통해 Remote repository로 넣어준다.


이 부분에 대해서 뭔가 말할 거리가 많다고 생각했는데,
막상 적다보니 짧은거 같아서 뭔가 조금 찜찜(?)한데.... 뭐 할 말은 다 한 것 같다!
빼먹은 부분이 있으면 나중에 다시 더 추가하도록 하고...
최신 트랜드에 따르기 위해서 요즘 유행한다는 인후염을 겪고 있다보니 헥헥....

바로 앞에서 Remote repository 를 clone 하여서 받아왔다.
이번에는 만든 work repository 에서 작업한 내용을 Server로 보내는 작업을 해보자.

더불어서 git 에서 한글파일명을 쓸 때 발생하는 문제까지 같이 살펴보겠다.



1. modify + error

$ nano ./한글파일명.txt $ git add ./한글파일명.txt $ git commit -m 'push + 한글파일명 검증'

위 스크린샷에 모든 것이 나와있다.

새로운 계정에서 repository를 clone 하였고,
해당 work repository에서 새로운 파일을 추가한 다음에
commit을 하고자 하는데 여기서 바로 error가 발생을 했다!

error가 발생한 이유는,
"commit 을 하려고 하는데 누가 commit을 하려는 건지 정체를 알 수가 없으니 알려줘!!!"



2. user

$ git config --global.email bigbang@whatwant.com $ git config --global.name bigbang $ git commit -m 'push + 한글파일명 검증'

앞에서 살펴본바와 같이 git을 사용하기 전에는 항상 환경 설정을 해줘야 한다.

   - http://whatwant.tistory.com/295

그런데,
위 스크린샷을 보면 특이한 점을 볼 수 있을 것이다. 무엇인지 찾으실 수 있으신가요?!



3. push

$ git push

다음에 다시 한 번 제대로 설명을 하겠지만,

일단, 위에서 진행한 'commit'은 Server와 별개로 현재 계정의 work repository에서 작업을 한 것이다.
작업한 내용을 Server로 보내는 작업이 필요한데, 그것이 바로 " git push"이다.

그런데, 위 스크린샷을 보면 알겠지만 그냥 넘어가지 않고, error가 발생을 한다!

우리에게 모든 것을 알려주시는 친절한 git 선생님의 말씀을 잘 읽어보면,
권한(permission)이 충분하지 않다고 나온다.
그렇다! 바로 권한!!!



4. permission

서버 즉, Remote repository 의 권한을 한 번 살펴보자.

위 스크린샷을 보면 user와 group에게는 모두 권한을 주고 있지만,
다른 사용자들에게는 읽기 권한만 주고 있는 것을 확인할 수 있다.

그렇다!
이전에 계속 말한바와 같이 git은 어디까지나 기본적인 파일 권한을 기반으로 사용한다.

그러면, 여러 계정이 이 repository를 사용하게 하려면 어떻게 해야할까?



5. group

$ sudo groupadd barerepo $ sudo usermod -G bigbang,barerepo bigbang

해당 repository를 사용하는 사용자들을 묶을 그룹을 하나 만들어보자.
   - sudo groupadd barerepo

사용자 'bigbang'을 barerepo 그룹에도 포함을 시키자.
   - sudo usermod -G bigbang.barerepo bigbang


일반적으로 'usermod'는 익숙하지 않을 것 같은데...
사용자의 정보를 변경하는 명령어이다. 그 중 '-G' 옵션은 그룹에 대한 정보를 변경한다는 의미이다.
여러 그룹에 속할 경우 ','로 나열을 하면 되고, 변경하고자 하는 계정은 제일 뒤에 적어주면 된다.

즉, 위 스크린샷에서는
" 'bigbang'이라는 계정은 'bigbang'이라는 그룹과 'barerepo'라는 그룹, 두 곳에 속한다! "
라는 의미이다.



6. chown

$ sudo chown -R chani.barerepo ./BareRepo.git

위 스크린샷을 차례대로 살펴보길 바란다.

   - 'BareRepo.git' 은 chani 계정이 생성하였다. (주인은 chani)
   - 'chown'을 통해서 소유 group을 'barerepo'로 변경하였다.


'chown' 이라는 명령어에 대해서 조금 더 설명을 하자면,
당연하게도 소유자를 변경(chage owner)하기 위해서 사용을 하는 것이고,
하위 디렉토리 및 파일들도 일괄적으로 변경하기 위해서는 '-R' 옵션을 사용하면 된다.
user와 group은 '.'으로 연결하면 된다.


이제, 'BareRepo.git' repository는 barerepo 그룹 사용자들에게도 쓰기 권한이 있다!!!



7. push

$ git push

이 부분을 테스트하면서 조금 의아심이 들었지만...
일단, 위에서 따라온 것처럼 권한 부분을 맞춰주면 스크린샷과 같이 정상적으로 push가 된다.

Remote repository로 변경 내역을 전달한 것이다!!!


여기서 의아하다는 점은,
분명 에러가 발생을 해야하는데 그냥 push가 되어버렸다는 점이다!!!

$ git config push.default tracking

본래는 push 를 어떻게 할 것인지 명시하지 않았기 때문에 error가 발생을 해야한다.
그런데, 왜 위 스크린샷에서 보는 것처럼 그냥 넘어갔는지는 의문이다.

만약, 여러분의 경우에 push할 때에 에러가 발생한다면,
혹 발생하지 않았더라도 위와 같이 tracking을 설정해놓으시길...



8. 한글파일명

한글 파일을 추가할 때 뭔가 이상하게 숫자들의 집합으로 등록이 된 것을 앞에서 확인했을 것이다.

bigbang@chani-Ubuntu:~/workspace/BareRepo$ git commit -m 'push + 한글파일명 검증' [master 5705788] push + 한글파일명 검증  1 files changed, 1 insertions(+), 0 deletions(-)  create mode 100644 "\355\225\234\352\270\200\355\214\214\354\235\274\353\252\205.txt"

잘못 등록된 것이 아니라 Unicode로 변경되어 전달된 것이다.
위 스크린샷을 보면 알겠지만, clone 을 하여도 제대로 파일명이 되어있는 것을 알 수 있을 것이다.

하지만, 위와 같이 등록이 될 경우에 일부 문제가 있을 수도 있다.
예를 들어서 Redmine의 저장소로 사용될 경우
파일의 이름이 한글이 아니라 저 숫자로 된 코드가 그대로 파일명으로 나오기도 한다.

$ sudo git config --system core.quotepath false

사용자 계정이 아니라 root 계정을 통해 system의 설정을 변경해야 한다.
이렇게 할 경우 다른 side effect가 있는지는 아직 모르겠다.

commit 부분을 살펴보면, 앞에서와 달리 한글이 그대로 반영되는 것을 볼 수 있을 것이다.


일단은 그냥 기본 값으로 사용하는 것을 추천하고,
Redmine의 경우와 같이 사용에 문제가 있을 경우 위와 같이 설정 변경을 통해 해결하는 것을 제안한다.

이로 인한 side effect에 대해서는 계속 확인을 해보겠다.



간만에 길게 쓴 포스팅인데, 춥고 졸리다! ㅠㅠ