Git 페이지의 소스 보기
마지막으로 [b]
-- Loading page list... --
내용출력
로그인[l]
Diary
[f]
최근변경내역
[r]
페이지목록[i]
횡설수설[2]
게시판[3]
링크
수정할 수 없습니다: Git 는 읽기 전용 페이지입니다.
<toc> <font size="+2"><color(red,한글과 관련된 문제에 대해서는 아래의 [[#unicode|버전 2.6.2]] 절을 우선 볼 것)></font> == # 좌충우돌하며 시작 == 리눅스에서는 설치하고 바로 사용하는데 큰 문제가 없는데, 윈도에서 msysgit 을 쓰자니 특히나 한글 처리 등 이런저런 문제들이 있었음. === # 검색하며 눈에 띈 문서들 === * [http://www.alistapart.com/articles/get-started-with-git/ Get Started with Git] * [http://tranbot.net/ALA/get-started-with-git/ Git시작하기] - 위 글의 번역 * [http://schacon.github.com/git/gittutorial.html gittutorial(7)] * [http://knol.google.com/k/github-%EC%82%AC%EC%9A%A9%ED%95%98%EA%B8%B0# github 사용하기 - a knol by WooKyoung Noh] * [http://binggrec.tistory.com/116 빙그레C의 Blog :: github 사용하기] * [http://dogfeet.github.com/articles/2012/progit.html dogfeet - progit] - "Pro Git" 번역판 ** [https://github.com/dogfeet/progit Github] * [http://dogfeet.github.com/articles/2011/a-successful-git-branching-model.html A successful Git branching model » nvie.com] * [https://backlogtool.com/git-guide/kr/ 누구나 쉽게 이해할 수 있는 Git 입문~버전 관리를 완벽하게 이용해보자~ | Backlog] === # cmd 대신 ckw 쓰기 === '''(최신 버전에서는 굳이 다른 대체품을 찾을 필요가 없다. [[#unicode|버전 2.6.2]] 절 참고.)''' <memo(낡은 내용이라 감춤)> "Git Bash"를 실행했을 때 불편하기 짝이없는 cmd 창보다는 ckw 를 이용하자. * "Git Bash.lnk" 바로가기의 등록 정보 들어가서 ** 대상: <code>C:\WINDOWS\system32\cmd.exe /c start "D:\Local\ckw_link\ckw.exe -e "C:\Program Files\Git\bin\sh.exe" --login -i"</code> * 위와 같이 설정하니까 되더라. 대상에 바로 ckw를 적어주지 않고 cmd를 먼저 실행하는 것은... ckw를 바로 실행하게 했더니 자그마한 cmd창이 같이 뜨고 타이핑하는게 양쪽 창에 다 찍히는 희한한 상황이 되어서였음. * ckw를 실행할 때 명령행 인자로 -bg, -fg 등으로 색상을 바꿔주거나 할 수 있다<footnote(매뉴얼[http://www.tatsuromatsuoka.com/ckw/Reference-en.txt] 참고)>. 일반적인 명령 프롬프트 창 대용으로 띄울 때와 구분되게 하니까 좋았음. * 문제는 탐색기에서 마우스 우클릭했을 때 뜨는 컨텍스트 메뉴인데, 이건 git-cheetah 라는 게 git설치할 때 같이 깔려서 그 부분을 담당하는데, 메일로 문의하니 재컴파일하지 않는 이상 고칠 수 없다고 함. 대신 msysgit설치할 때 git-cheetah 대신 registry 기반 컨텍스트 메뉴를 사용하게 설치할 경우, <code>(HKLM 또는 HKCU)\SOFTWARE\Classes\Directory\shell\git_shell\command</code>에서 수정할 수 있다고 함 * 위의 내용은 윈도XP에서 주인장이 설정한 것이고, 윈도7은 좀 다른 듯 하다. 아래 Comments 참고. * 주인장의 경우는 윈도7에서 다음과 같이 했음 ** <code>C:\Windows\SysWOW64\cmd.exe /c start D:\Local\ckw_link\ckw.exe -e "C:\Program Files (x86)\Git\bin\sh.exe" --login -i</code> ** 배경색 등의 설정은 ckw.exe 와 -e 사이에 <code>-cd D:\Work\Git -fg black -bg gray</code>와 같은 식으로. </memo> === # 벨소리 없애기 === '''([[#unicode|버전 2.6.2]] 절 참고.)''' <memo(낡은 내용이라 감춤)> "Git Bash"에서 커맨드 라인에서 명령어의 앞부분을 타이핑하고 탭을 눌러 자동완성을 할 때, 후보가 두 개 이상이면 벨이 울리는데, 이게 PC 케이스의 스피커에서 나온다 -_-;;; 자기 홈 디텍토리에 <code>.inputrc</code> 파일을 만들고 다음과 같이 적어준다.<footnote([http://www.mariopareja.com/blog/archive/2009/04/20/disable-annoying-beep-sound-for-git-on-windows.aspx])> {{{#!vim sh # Don't ring bell on completion set bell-style none }}} git log 등에서 less를 실행하는데 less도 벨을 울린다. * git의 <code>core.pager</code>를 <code>"less -q"</code>로 설정<footnote([http://stackoverflow.com/questions/1266545/disable-beep-in-git-diff-on-windows])> 위와 같이 하면, less 출력 시 제일 첫 줄에서 위로 가려 하거나 제일 마지막 줄에서 더 아래로 가려 할 때 나오는 벨은 멈추지만, 다른 상황에서의 벨은 여전히 울린다. 아예 윈도우 자체에서 벨을 꺼버리는 건<footnote([http://blog.netnerds.net/2007/05/5-ways-to-stop-windows-vista-xp-2003-from-beeping/])> * 장치 관리자 - 보기 - 숨김 장치 표시 - 비 플러그 앤 플레이 드라이버 - Beep - 이 장치 사용 안 함 </memo> === # 한글 출력 === '''([[#unicode|버전 2.6.2]] 절 참고.)''' <memo(낡은 내용이라 감춤)> Git Bash 쉘에서 한글이 안 보인다. <code>~/.inputrc</code>에<footnote([http://czstyle.tistory.com/29])> {{{#!vim sh set output-meta on set convert-meta off }}} <code>ls</code>에서 한글 파일명이 안 보인다. <code>~/.bashrc</code>에<footnote([http://czstyle.tistory.com/29])> {{{#!vim sh alias ls='ls --show-control-chars' }}} <code>less</code>에서도 한글이 안 나와서 commit과 log 볼 때 문제<footnote([http://yotteum.tistory.com/28])> {{{#!vim sh export LESSCHARSET=latin1 }}} </memo> === # 에디터 바꾸기 === commit할 때 사용하는 에디터를 gvim으로 바꾸고 싶으면 <code>GIT_EDITOR</code> 환경 변수를 정해주면 됨. 다만 bash를 거치기 때문에 경로를 다음과 같이. {{{#!vim sh export GIT_EDITOR=/d/Local/Vim/vim72/gvim.exe }}} [[VimEditor]] 7.2부터는 git 설정파일 등의 신택스 하일라이팅이 지원되는데, 그 이전 버전은 다음과 같이 하면 된다<footnote(git소스 디렉토리의 <code>contrib/vim/README</code>)> <memo(길어서 감춤)> {{{ Syntax highlighting for git commit messages, config files, etc. is included with the vim distribution as of vim 7.2, and should work automatically. If you have an older version of vim, you can get the latest syntax files from the vim project: http://ftp.vim.org/pub/vim/runtime/syntax/git.vim http://ftp.vim.org/pub/vim/runtime/syntax/gitcommit.vim http://ftp.vim.org/pub/vim/runtime/syntax/gitconfig.vim http://ftp.vim.org/pub/vim/runtime/syntax/gitrebase.vim http://ftp.vim.org/pub/vim/runtime/syntax/gitsendemail.vim These files are also available via FTP at the same location. To install: 1. Copy these files to vim's syntax directory $HOME/.vim/syntax 2. To auto-detect the editing of various git-related filetypes: $ cat >>$HOME/.vim/filetype.vim <<'EOF' autocmd BufNewFile,BufRead *.git/COMMIT_EDITMSG setf gitcommit autocmd BufNewFile,BufRead *.git/config,.gitconfig setf gitconfig autocmd BufNewFile,BufRead git-rebase-todo setf gitrebase autocmd BufNewFile,BufRead .msg.[0-9]* \ if getline(1) =~ '^From.*# This line is ignored.$' | \ setf gitsendemail | \ endif autocmd BufNewFile,BufRead *.git/** \ if getline(1) =~ '^\x\{40\}\>\|^ref: ' | \ setf git | \ endif EOF }}} </memo> === # 그 외 === '''([[#unicode|버전 2.6.2]] 절 참고.)''' <memo(낡은 내용이라 감춤)> less 출력할 때마다 "WARNING: terminal is not fully functional"라는 경고가 뜬다<footnote([http://code.google.com/p/msysgit/issues/detail?id=184])> {{{#!vim sh export TERM=msys }}} </memo> == # 커밋 메시지의 인코딩 == '''([[#unicode|버전 2.6.2]] 절 참고.)''' <memo(낡은 내용이라 감춤)> 일단 관련되는 옵션은 두가지: (git-commit[http://schacon.github.com/git/git-commit.html] 참고) * <code>i18n.commitencoding</code> : <code>git commit</code>과 <code>git commit-tree</code>에서, 커밋 로그 메시지가 UTF-8이 아닐 때 경고를 내는데, 사용자가 명시적으로 메시지의 인코딩을 명시해주어서 해결할 수 있다. {{{#!vim gitconfig [i18n] commitencoding = cp949 }}} : 이 옵션이 켜진 상태에서 생성된 커밋 오브젝트에는 옵션의 값이 <code>encoding</code> 헤더에 붙는다. <code>git cat-file -p 커밋</code>해서 뽑아보면 <code>encoding cp949</code>라 적힌 헤더를 볼 수 있음 {{{#!vim git tree bf7eb54d1d9dc603d34f6b6dc84b4b9db0c18173 parent 84d66d805b2b86605fbaaa19beb819ef52f3f7cf author *** <***> 1326542980 +0900 committer *** <***> 1326542980 +0900 encoding cp949 cp949 [안녕하세요] both options on }}} : 그런데 이 헤더를 붙여놓고 (즉 이 옵션을 켜놓고) 메시지를 UTF-8로 인코딩해서 저장해버리면 제대로 볼 수 없게 되니 조심 * <code>i18n.logoutputencoding</code> {{{#!vim gitconfig [i18n] logoutputencoding = cp949 }}} : <code>git log</code>, <code>git show</code>, <code>git blame</code> 등은 커밋 오브젝트의 <code>encoding</code>헤더를 본 후, 로그 메시지를 UTF-8로 재인코딩하려 한다. 이 때 위 옵션을 써서 원하는 출력 인코딩을 지정할 수 있음. : 이 옵션이 없는 경우, <code>i18n.commitencoding</code>의 값을 사용함 MS 윈도우에서 msysgit 를 사용하면서, 이 옵션에 따라 커밋 메시지가 어떻게 보이는지를 테스트 해 보았음: * 일단 ls, less와 터미널 설정 등은 위 절에 있는 내용을 따랐다. * 옵션 두 가지를 각각 켜고 끄면서, 커밋 메시지를 두 가지 인코딩을 각각 사용하면 총 8가지 경우에 대해서 다음 세 가지 항목을 살펴봄 ** 커밋할 때 경고가 뜨는가 ** 커밋한 직후에 <code>git log -1</code>해서 그 커밋을 출력할 때 제대로 보이는가 ** github에서 커밋 메시지가 제대로 보이는가 * 옵션 두 가지를 각각 켜고 끌 때 <code>git log</code> 하면 일련의 서로 다른 인코딩이 적용된 커밋 메시지가 어떻게 보이는가를 살펴봄 || 옵션 설정 || cp949 인코딩한 커밋 || UTF-8 인코딩한 커밋 || git log 했을 때 || || 옵션 없음 |< 커밋할 때 경고(*)<br>로그 잘 나옴<br>github 깨짐 |< 커밋 잘 됨<br>로그 깨짐<br>github 잘 나옴 |< commitencoding 옵션을 끄고<br> cp949 인코딩하여 커밋했던 메시지만<br> 제대로 나오고 나머지는 깨져보임<br>[Upload:test1_no_option.png 스크린샷1] || || i18n.commitencoding=cp949 |< 커밋 잘 됨<br>로그 잘 나옴<br>github 깨짐 |< 커밋 잘 됨(**)<br>로그 깨짐<br>github 잘 나옴 |< 다른 경우는 잘 나오고<br>commitencoding 옵션을 켜고<br>UTF-8 인코딩했던 메시지는 깨짐<br>[Upload:test2_commitencoding.png 스크린샷2] || || i18n.logoutputencoding=cp949 |< 커밋할 때 경고(*)<br>로그 잘 나옴<br>github 깨짐 |< 커밋 잘 됨<br>로그 잘 나옴<br>github 잘 나옴 |< 두번째 경우와 동일 || || 두 옵션 다 적용 |< 커밋 잘 됨<br>로그 잘 나옴<br>github 깨짐 |< 커밋 잘 됨(**)<br>로그 깨짐<br>github 잘 나옴 |< 두번째 경우와 동일 || ** github 에서 커밋 히스토리를 볼 때의 [Upload:test_commit_history.png 스크린샷3] ** (*) 경고 메시지는 다음과 같음 {{{ Warning: commit message does not conform to UTF-8. You may want to amend it after fixing the message, or set the config variable i18n.commitencoding to the encoding your project uses. }}} ** (**) 이 경우는, 메시지 인코딩이 cp949라고 해 놓고는 실제로 UTF-8인코딩된 메시지를 넘겨주었으니, 잘 되는 게 이상한 듯? 결론적으로 * github를 생각하면 무조건 UTF-8인코딩을 써야 하고 * 명령 프롬프트 창에서 git log 등을 할 때 깨지지 않으려면 <code>i18n.logoutputencoding=cp949</code> 만 적용 여담으로, * 프로젝트 내용물 중에 README 파일이 있으면 github에서 그 내용을 첫 화면에 같이 보여주는데, 이 파일은 UTF-8로 인코딩하거나 cp949로 인코딩하거나 상관없이 화면에 잘 나왔다. 이거 참 신기하다. cp949는 euc-jp 등과 겹칠 우려가 있지 않은가? * README 파일의 인코딩을 바꾸어가며 커밋하고 github에서 각 커밋을 클릭해서 diff를 보면, 인코딩이 바뀔 때의 diff는 깨져서 나오지만, 같은 인코딩끼리라면 한글 문자열의 diff도 잘 보여 주었음 </memo> == # Merge와 Diff를 외부 프로그램 쓰기 == 위에 있는 "Pro git" 번역판 7장에 "다른 Merge, Diff 도구 사용하기" 섹션이 있는데, 윈도우에서 하려니 잘 안 되는 부분이 있어서, 이래저래 구글링도 하고 직접 테스트 하면서 알아낸 것 정리. 일단 책에 소개된 P4Merge[http://www.perforce.com/product/components/perforce_visual_merge_and_diff_tools]와, [[VimEditor]]를 쓰는 걸 생각해 보자. * P4Merge 설치는 다운로드 페이지[http://www.perforce.com/downloads/complete_list]에서, by component - Clients - Visual Merge Tool 로 선택한 후 윈도우용을 받고, 설치할 때 Merge Tool만 설치하면 됨 === # vimdiff로 Merge === <code>git merge</code>를 했을 때 충돌이 나서 자동으로 merge할 수 없다고 나오면, get mergetool 명령을 써서 병합 도구를 띄울 수 있는데, 이 때 vim을 띄우는 세팅: {{{#!vim gitconfig [merge] tool = vimdiff [mergetool "vimdiff"] path = d:/Local/Vim/vim72/gvim.exe }}} * vimdiff 는 Git에서 기본으로 지원하는 값이고, msysgit에는 vim도 같이 들어있다. 따라서 <code>merge.tool = vimdiff</code> 이것만으로도 충분하다. 그러나 vim이 뜨면 명령 프롬프트 창에서 작업을 해야 하는데 좀 불편하니, 원래 PC에 설치되어 있던 gvim을 띄우기 위해서 path로 gvim.exe를 지정해준다. * gvim은 텍스트의 인코딩을 알아서 판별할 수 있기 때문에 인코딩 걱정은 안 해도 된다. * [Upload:merge_vimdiff.png vimdiff를 사용하여 병합하는 스크린샷] - 4분할된 버퍼 중 하단이 병합 후 모습인데, 아래 p4merge와 조금 다르게 <code><<<< HEAD</code> 이런 문구가 그대로 보인다. === # p4merge로 Merge === p4merge는, 소스 파일들이 주로 어떤 인코딩으로 저장되어 있냐에 따라 좀 다르다. ==== # 시스템 디폴트 인코딩(cp949)를 쓸 경우 ==== 병합할 대상 파일들이 주로 cp949로 인코딩되어 있다면, 비교적 간단(?)하게 가능하다: {{{#!vim gitconfig [merge] tool = p4merge [mergetool "p4merge"] path = c:/Program Files/Perforce/p4merge.exe }}} * "Pro Git" 책에는 <code>mergetool.p4merge.cmd</code> 옵션을 설정해서 호출할 때 인자를 넘겨주는 방법을 지정해야 한다고 나왔으나, stack overflow 등에서 답변들을 보니 최신 버전의 git은 p4merge를 자체적으로 지원하므로 필요없어짐 * 그러나 p4merge.exe가 PATH에 잡혀 있더라도 그냥은 실행이 안 되고, <code>path</code>를 지정해주어야 하더라. 지정해 줄 때도 저렇게 윈도우용 경로명을 직접 적어주면 자꾸 슬래쉬가 이스케이프되어 버려서 잘 안 된다. msysgit의 Git bash에서 다음과 같이 지정해주는 게 낫다 {{{#!vim sh $ git config mergetool.p4merge.path /c/Program\ Files/Perforce/p4merge.exe }}} * [Upload:merge_p4merge.png P4Merge를 사용하여 병합하는 스크린샷] - master 브랜치와 devel 브랜치에서 merge.txt의 같은 라인을 수정할 때 ==== # UTF-8로 인코딩을 쓰는 경우 ==== 소스 코드 파일들이 UTF-8로 인코딩되어 있다면... 이러면 좀 더 복잡해진다. p4merge는 실행 후 메뉴에서 인코딩을 바꿀 수 있다. 따라서 위처럼 설정하고 p4merge를 실행할 때마다 직접 바꿔줘도 되겠지만 귀찮다. 또 p4merge는 명령행 옵션을 써서 인코딩을 옵션으로 줄 수도 있다! 그런데, 문제는 Git가 p4merge를 불러오는 과정에서 그 옵션을 삽입하게 할 방법이 없다<footnote(<code>C:\Program Files\Git\libexec\git-core\mergetools\p4merge</code> 스크립트 참조 [https://github.com/gitster/git/blob/master/mergetools/p4merge github에서 보기]. path값에 옵션을 추가하더라도, 저 스크립트에서 따옴표로 둘러싸여 있으므로 통채로 실행하려고 해서 에러가 난다.)> 별 수 없이, wrapper 스크립트를 만든다. {{{#!vim sh #!/bin/sh /c/Program\ Files/Perforce/p4merge.exe -C utf8 "$1" "$2" "$3" "$4" }}} 그리고 .git 옵션에서는 p4merge의 path를 저 스크립트로 바꿔치기 한다. {{{#!vim gitconfig [merge] tool = p4merge [mergetool "p4merge"] path = c:/Program Files/Git/bin/extMerge }}} (사실 내가 merge를 직접 해야 할 일이 얼마나 있을까 생각해보면... 그냥 처음처럼 두어도 되었을 걸 -_-) === # vimdiff로 diff === diff는 merge하고 상황이 다른데, merge야 충돌 나면 그때가서 충돌난 파일을 에디터로 열어서 손으로 찾아가며 해도 되지만, diff는 <code>git diff</code>를 할 때마다 터미널 창에 뜨는데 UTF-8은 다 깨져나와서, 별 수 없이 리다이렉션으로 일단 저장하고 열어보는 수고를 해야 한다. 아니면 파이프로 iconv에게 넘겨줘도 되는데 이러면 색상 구분이 다 없어져 버린다. 일단 vimdiff로 diff를 보는 것부터 얘기하자. diff도 두가지가 있다. * <code>git diff</code>[http://schacon.github.com/git/git-diff.html] - 이건 <code>diff.external</code> 옵션으로 제어하고, 인자는 무조건 7개가 전달된다[http://schacon.github.com/git/git.html] ** 전달되는 인자: <code>path old-file old-hex old-mode new-file new-hex new-mode</code> * <code>git difftool</code>[http://schacon.github.com/git/git-difftool.html] - 이건 merge와 유사하게 <code>diff.tool</code> 옵션으로 제어하고, 만일 이 옵션의 값이 없으면 <code>merge.tool</code> 값을 사용한다. tool옵션의 값이 Git가 지원하는 프리셋 중 하나라면 거기에 맞춰 인자가 넘어가고, 그 외의 경우는 <code>difftool.툴이름.cmd</code>에서 지정해 주어야 한다. <code>git difftool</code>에서만 vim을 쓰고 싶다면 툴만 지정해주면 된다. gvim을 원한다면 merge할 때와 같이 path도 지정. {{{#!vim gitconfig [diff] tool = vimdiff }}} <code>git diff</code>에서도 vim을 쓰고 싶다면 좀 복잡하다. 여기에는 vimdiff 프리셋 같은 게 없어서 일일이 명령어와 인자를 명시해줘야 한다. 여기서도 wrapper 스크립트를 만들어주자. Git bash 상에서 <code>/bin/extDiff</code> 스크립트를 만든 후, 다음과 같이 적는다: {{{#!vim sh #!/bin/sh /d/Local/Vim/vim72/gvim.exe -d "$2" "$5" }}} * 넘어온 7개의 인자 중에 2번째와 5번째가 각각 로컬 파일, 리모트 파일의 이름이다. 그 다음 gitconfig 에서는 <code>diff.external</code> 값을 설정한다: {{{#!vim gitconfig [diff] external = extDiff }}} === # p4merge로 diff === 이게 아주 해괴망칙한 부분인데... 두 커밋 또는 커밋과 작업 디렉토리 등을 비교할 때, 파일이 양쪽에 다 존재하면 괜찮은데, 중간에 파일을 새로 생성했다거나 삭제를 했다면 어느 한쪽에는 파일이 없다. 문제는 그 없는 파일이 diff를 할 때 <code>/dev/null</code>이라는 경로명으로 diff 프로그램에 넘어간다는 거다. Git의 기본 diff는 이걸 잘 처리해주고 (빈 파일처럼 다루어 비교함), vimdiff도 마찬가지인데, p4merge 는 인자로 이 이름을 받으면 잘못된 파일이라고 에러를 낸다. (이 문제에 대해서는 stackoverflow를 비롯해서 구글링을 여러 차례 해도 나오는 게 없더라. 윈도 msysgit에서 p4merge를 사용하는 법을 묻는 질문은 종종 있던데, 다들 이 문제는 포기하고 살았던 걸까, 아니면 나만 겪고 있나?) 어차피 인코딩 옵션 때문에 wrapper 스크립트를 쓰긴 해야 하는데, 이 문제 때문에 인자를 미리 검사해서 p4merge를 속이는 일도 해줘야 한다. diff와 difftool 양쪽에서 다 p4merge를 쓰는 경우를 가정하자. wrapper 스크립트는 다음과 같이 작성한다. {{{#!vim sh #!/bin/sh # %TEMP% 디렉토리에 저장될 임시파일명. PC내에서 절대 겹치지 않을 것 같은 이름을 지어준다 BLANKFILE="${TEMP}/_blank_" if [ $# -eq 7 ] then # 'git diff' LOCAL=$2 REMOTE=$5 else echo "I got $# arguments. ERROR!" exit 1 fi if [ "$LOCAL" == '/dev/null' ] then touch $BLANKFILE LOCAL=$BLANKFILE fi if [ "$REMOTE" == '/dev/null' ] then touch $BLANKFILE REMOTE=$BLANKFILE fi /c/Program\ Files/Perforce/p4merge.exe -C utf8 "$LOCAL" "$REMOTE" rm -f $BLANKFILE }}} * 인자로 <code>/dev/null</code>을 받으면, <code>%TEMP%</code> 디렉토리에 빈 파일 하나를 만들고 그 파일 이름으로 인자를 바꿔치기하여 p4merge에 전달한다. 그리고 git에서는 다음과 같이 설정 {{{#!vim gitconfig [diff] external = extDiff tool = extDiff [difftool "extDiff"] cmd = extDiff \"\" \"$LOCAL\" \"\" \"\" \"$REMOTE\" \"\" \"\" }}} * cmd의 값이 복잡한 건 빈 인자를 끼워넣어 인자를 7개 만드느라 그렇다. 여기가 지저분하면 그냥 <code>$LOCAL</code>과 <code>$REMOTE</code> 두 개만 넘겨주고, 스크립트 쪽에서 <code>$1</code>과 <code>$2</code>로 각각 받아도 되겠는데, 이건 <code>git difftool</code>에만 적용되고 <code>git diff</code>는 여전히 인자가 7개 넘어가니까, 스크립트 쪽에서 인자의 갯수를 비교해서 할당해줘야 해서 더 귀찮다. [Upload:diff_p4merge.png P4Merge를 사용한 diff 스크린샷] - 왼쪽 창은 비교 대상 중 한쪽에 파일이 없는 경우. 실제로는 저렇게 창들이 한꺼번에 뜨지 않고, 파일 하나마다 뜨고 닫으면 다음 창이 뜬다. === # DiffMerge로 merge, diff 하기 === * [http://www.sourcegear.com/diffmerge/ SourceGear | DiffMerge | overview] - 이게 DiffMerge 홈페이지 아래는 DiffMerge를 언급하는 글들 * [http://ljh131.tistory.com/143 ljh131@blog :: 본격 diff 툴 비교 리뷰 - Beyond Compare의 승!] * [http://dogfeet.github.com/articles/2011/git-mergediff.html dogfeet - Git:mergetool, difftool] * [http://jerevinan21.tistory.com/156 빌딩 숲 속의 개발자.. :: GIT DiffMerge 설정.] 글을 보고 호기심이 나서 설치해 봄. <code>git mergetool</code>할 때 사용하기 위한 설정은 쉽다. 위에 링크된 글들을 참고하고, 나는 다음과 같이 <code>.gitconfig</code>파일에 적었다. {{{#!vim gitconfig [merge] tool = diffmerge [mergetool "diffmerge"] cmd = \"c:/Program Files/SourceGear/Common/DiffMerge/sgdm.exe\" --merge --result=\"$MERGED\" \"$LOCAL\" \"$BASE\" \"$REMOTE\" trueExitCode = true }}} 뒤에 인자를 적는 부분에 꼬박꼬박 따옴표를 해 준 이유는, 역시 파일명에 공백이 있을 경우를 대비해서. diff는, p4merge와 같은 이유로 귀찮다. 일단 <code>git difftool</code>을 위한 간단한 설정은: {{{#!vim gitconfig [diff] tool = diffmerge [difftool "diffmerge"] cmd = \"c:/Program Files/SourceGear/Common/DiffMerge/sgdm.exe\" \"$LOCAL\" \"$REMOTE\" }}} 그러나 p4merge에서처럼, 만일 두 스냅샷을 비교하는데 파일이 어느 한쪽에서만 존재하면, 존재하지 않는 쪽이 "nul"이라는 파일명으로 넘어가는 바람에 에러창이 뜨고, 에러창을 닫으면 또 DiffMerge창도 무의미하게 한 번 더 닫아줘야 한다. 그래서 할 수 없이 wrapper를 만든다. 내 경우는 다른 건 다 p4merge에서와 똑같이 하고, extDiff 스크립트 내에서 프로그램 호출하는 부분만 바꿔 적었다. {{{#!vim gitconfig # 이건 그대로 [diff] tool = extDiff [difftool "extDiff"] cmd = extDiff \"\" \"$LOCAL\" \"\" \"\" \"$REMOTE\" \"\" \"\" }}} {{{#!vim sh # /c/Program\ Files/Perforce/p4merge.exe -C utf8 "$LOCAL" "$REMOTE" 이거 대신 /c/Program\ Files/SourceGear/Common/DiffMerge/sgdm.exe "$LOCAL" "$REMOTE" }}} <code>git diff</code>의 경우는 diff.external 옵션값을 extDiff로 바꿔주면 되겠으나, 그동안 좀 더 사용하다보니까 git diff는 터미널에서 그냥 하는 게 나을 때도 많고 해서 이건 건드리지 않았다. (위에 dogfeet님 블로그 글과 같은 이유) 끝으로, DiffMerge는 기본 텍스트 인코딩을 ISO-8859인가로 잡아놨기 때문에 한글이 포함된 문서를 볼 때 제대로 안 보인다. * Tool - Option - File Windows (여기서 글꼴 변경) - Rulesets 메뉴에 들어가서, Default Ruleset 또는 커스텀 룰셋 각각의 Edit 들어가보면 인코딩을 지정할 수 있다. == # [#concat]두 저장소를 잇기 == * [http://stackoverflow.com/questions/3147097/how-to-prepend-the-past-to-a-git-repository How to prepend the past to a git repository? - Stack Overflow] * [https://git.wiki.kernel.org/articles/g/r/a/GraftPoint_2c06.html GraftPoint - Git SCM Wiki] == # SSH로 서버에서 받아올 때 PATH 문제 == 리눅스 서버에 git 저장소를 하나 만들고, 그걸 윈도우 머신에서 복사하려고 (github를 거치지 않고) 시도했는데 아래와 같이 에러가 났다. {{{ $ git clone gypark@gypark.pe.kr:/home/gypark/temp/cvstest/testwiki.git Cloning into 'testwiki'... gypark@gypark.pe.kr's password: bash: git-upload-pack: command not found fatal: The remote end hung up unexpectedly }}} 서버의 내 아이디 gypark에서 <code>git-upload-pack</code>을 실행시킬 수 없었던 건데, 이 시점에서는 <code>.bashrc</code>만 적용되고 <code>.bash_profile</code>에 있는 $PATH 설정은 적용이 안 되더라. .bashrc쪽에서 PATH를 지정해주어 해결 == # CVS에서 Git로 이전하기 == [[CVS]]로 관리하던 [[UseModWiki소스수정]]을 github로 옮겼는데, 그간 중앙 집중형 버전관리시스템의 대세가 확실히 [[Subversion]]으로 넘어갔던 건지, svn에서 이전하는 건 Git 자체에서도 지원하는 듯 한데, CVS에서 옮기는 얘기는 은근히 잘 찾을 수가 없더라. cvs-svn-git로 두 번 넘어가야 하나, 그간 수백번의 리비전이 있었는데 제대로 옮겨지려나 걱정을 많이 했다. 그런데 막상 해보니, Git를 만져본 후 이게 가장 쉬웠다고 할 정도로 무난히 성공했음. * http://cvs2svn.tigris.org/ - cvs2svn 홈 * http://cvs2svn.tigris.org/servlets/ProjectDocumentList - cvs2svn 다운로드 * http://cvs2svn.tigris.org/cvs2git.html - cvs2git 설명. 아래 적은 내용은 기본적으로 다 이 페이지에 언급되어 있다. 필요한 것: * CVS 저장소에 있는 파일들(*,v 형식의)에 직접 접근할 수 있어야 한다. 원격으로는 안 됨 * python2 2.4 이상. 3.*는 안 된다고 함 * rcs의 <code>co</code> 또는 cvs의 <code>cvs</code>를 쓸 수 있어야 함 * Git 1.5.4.4 이상 절차: * cvs2svn을 적당한 위치에 압축을 푼다. (따로 설치를 할 필요는 없고, 그 디렉토리 내에서 <code>cvs2git</code> 실행파일을 실행함) * cvs2svn-example.options 파일을 복사해서 수정한다. 매번 실행할 때 명령행 인자로 주는 것보다 이게 계속 써먹을 수 있으니 좋다. ** 기본설정을 거의 그대로 쓰는데, 내가 수정한 부분만 표시하면 다음과 같다: ** 실행을 하면 Git에 넘겨줄 덤프 파일 두 개가 생성되는데, 기본적으로 cvs2svn-tmp 디렉토리가 만들어지고 그 아래에 생긴다. 여기서는 그 중 하나인 blob들의 덤프파일이 생성될 위치이다. {{{#!vim python ctx.revision_recorder = SimpleFulltextRevisionRecorderAdapter( ... # GitRevisionRecorder('cvs2svn-tmp/git-blob.dat'), GitRevisionRecorder('/home/gypark/temp/cvstest/testwiki-blob.dat'), ) }}} ** 기본적으로 브랜치나 태그를 다 복원하는데, 이렇게 했더니 내가 CVS에서 관리할 때 만들었던 태그나 브랜치들이 꽤 복잡하게 얽히더라. 어차피 크게 중요한 게 아니었던 터라, 그런 걸 다 제외하고 메인 트렁크만 복원하도록 하였다: {{{#!vim python # ctx.trunk_only = False ctx.trunk_only = True }}} ** CVS 커밋의 저자명, 로그메시지, 파일네임 들을 유니코드로 변환할 때 사용할 인코딩 목록. 내 경우 위키 소스를 ext1.* 버전에서는 euc-kr로 작성했고 CVS 커밋 메시지도 마찬가지였다. (간혹 에디터 설정 실수로 UTF-8로 작성한 메시지들이 섞여 있음) 그래서 utf-8, cp949, ascii 순으로 시도하도록 적어주었다: {{{#!vim python ctx.cvs_author_decoder = CVSTextDecoder( [ #'latin1', #'utf8', # gypark 'utf8', 'cp949', 'ascii', ], #fallback_encoding='ascii' ) ctx.cvs_log_decoder = CVSTextDecoder( [ #'latin1', #'utf8', # gypark 'utf8', 'cp949', 'ascii', ], #fallback_encoding='ascii' ) # You might want to be especially strict when converting filenames to # Unicode (e.g., maybe not specify a fallback_encoding). ctx.cvs_filename_decoder = CVSTextDecoder( [ #'latin1', #'utf8', # gypark 'utf8', 'cp949', 'ascii', ], #fallback_encoding='ascii' ) }}} ** CVS에서 커밋에 author정보가 없는 부분(브랜치를 생성하는 시점 등)에 사용할 아이디. 다른 커밋에서 사용하던 그 아이디를 적어주었음: {{{#!vim python # ctx.username = 'cvs2svn' ctx.username = 'gypark' }}} ** CVS 커밋의 author는 단순한 아이디로 되어 있는데, 이걸 Git 커밋에서 사용하는 <code>이름 <메일></code> 형태로 매핑하기 위한 테이블. 위에 적었던 아이디도 여기에 적어준다. {{{#!vim python author_transforms={ ... # gypark 'gypark' : ('내 이름', '내메일주소'), } }}} ** 앞에서 얘기한 두 개의 덤프 파일 중 나머지 하나의 경로명을 적어준다. {{{#!vim python ctx.output_option = GitOutputOption( # The file in which to write the git-fast-import stream that # contains the changesets and branch/tag information: # 'cvs2svn-tmp/git-dump.dat', '/home/gypark/temp/cvstest/testwiki-dump.dat', ... ) }}} ** 가장 핵심이 되는, 변환할 CVS 저장소의 경로명 {{{#!vim python run_options.set_project( # The filesystem path to the part of the CVS repository (*not* a # CVS working copy) that should be converted. This may be a # subdirectory (i.e., a module) within a larger CVS repository. # r'test-data/main-cvsrepos', r'/home/gypark/CVS/testwiki', ... ) }}} * 이제 실행해서 덤프 파일을 생성한다. {{{#!vim $ cvs2git --options=옵션파일이름 }}} ** 저장소에 있는 *,v 파일들을 주욱 읽은 후에, 이러쿵 저러쿵 하는 메시지들을 쏟아내고 끝난다. ** 종료된 후에 확인해보면 위에 설정 파일에서 언급했던 두 개의 .dat 파일이 생성된 것을 알 수 있다. * Git 저장소를 새로 만든다. {{{#!vim $ mkdir testwiki.git $ cd testwiki.git $ git init }}} * 생성된 덤프 파일을 cat으로 출력하면서 git에 파이프로 넘겨준다 {{{#!vim $ cat ../testwiki-blob.dat ../testwiki-dump.dat | git fast-import }}} ** 테이블 형태의 메시지를 쭉 출력하고 끝난다. * 잘 변환되었는지 <code>git log</code>, <code>gitk</code> 등을 써서 확인 ** [Upload:cvs2git.png 스크린샷] 만세~ ** 좌측은 <code>cvs log wiki.pl</code>로 wiki.pl 파일의 커밋 로그를 출력했고, 우측은 <code>git log</code>로 전체 로그를 출력해보았음. git의 log는 전체 스냅샷을 대상으로 하기 때문에, 다른 파일에 해당되는 로그들이 같이 섞여 있다. 물론 <code>git log wiki.pl</code>하여 비교할 수도 있고, 정확히 일치함 * 막상 <code>ls</code>해 보면 파일이 하나도 없다! 당황하지 말고 <code>git checkout master</code>해서 체크아웃 한 번 해 준다. 여기까지가 정말 일사천리로 끝났다. 위에서 변환한 건 euc-kr을 사용하던 ext1.* 버전의 저장소인데, 총 커밋 횟수가 480회 정도 되고, 중간에 커밋 메시지가 에디터 설정 실수로 UTF-8로 끼어든 것들도 여럿 있고 그랬다. 그런데 전혀 에러나 오류 없이 깔끔히 변환되었다. 도저히 한번에 성공할 거라 생각하지 못해서, 일단 연습용 CVS저장소를 새로 만들고 커밋을 몇 번 한 후 변환을 시도하며 연습했었는데, 연습할 필요조차 없었지 싶다. 감탄했음. 그 다음은 UTF-8 기반으로 시작한 ext2.* 버전 저장소를 변환했다. 설정 파일에서 저장소 위치와 덤프 파일 이름만 바꿔주고는 한번에 성공. 이러고 나니까, 이왕 옮긴 김에, 두 Git 저장소를 하나로 통합하고 싶어졌다. ext1.* 버전에서 ext2.* 버전으로 죽 변경내역이 이어지도록 이어 붙이고 싶어진 것이다. 이건 어렵지 않게 구글링으로 성공했다. 위에 [[#concat|두 저장소를 잇기]]절에 있는 내용을 참고. * ext1.*버전의 저장소의 커밋이 <code>a-b-c-d</code>순으로 커밋되었고, ext2.*버전 저장소에 커밋이 <code>h-i-j</code>순으로 커밋되었다면, 첫번째 커밋인 h는 parent가 없는데, <code>h</code>의 parent가 <code>d</code>인 것처럼 속여 주는 것이다. * 일단 통합 저장소를 하나 생성한다. * 그 저장소에서 ext2.* 버전의 덤프 파일을 다시 fast-import 하여 복원한다. * 복원한 후, 현재 저장되어 있는 가장 첫번째 커밋의 SHA값을 기록해 둔다. {{{#!vim [gypark@www UseModKr]$ git rev-list --reverse master | head -1 92de4e3fdcd017fa0692069d3dcb57e93ab5bcec }}} * 그 다음은 이보다 더 이전 커밋들, 즉 ext1.* 버전의 커밋과 커밋들이 가리키는 객체들을 이 저장소에 담아와야 하는데... 이걸 어떻게 해야 될지 몰라서, 그냥 ext1.* 버전의 덤프 파일을 가지고 다시 한 번 fast-import했다. (이 과정에서 뭔가 필요한 정보를 덮어써버렸거나, 반대로 불필요한 정보가 추가되어 버렸을 가능성이 있다는 얘기인데, 딱히 이래저래 나중에 비교해봤는데 그러진 않은 듯) {{{#!vim [gypark@www UseModKr]$ cat ../testwiki-blob.dat ../testwiki-dump.dat | git fast-import warning: Not updating refs/heads/master (new tip 65919c894b1e19183c380d27093b5a08089186c1 does not contain 1fe3f81b4760efa38911f49905b0241eaaea3848) }}} ** 위와 같이, 새로 임포트하는 커밋들이 현재 저장소에 있는 첫번째 커밋과 이어지지 않아서 경고가 나온다. * ext1.* 버전 저장소의 가장 마지막 커밋의 SHA값을 찾아 기록한다. ** 그쪽 저장소에 가서 찾아도 되지만, 위 경고 메시지에 나온 <code>65919c894b1e19183c380d27093b5a08089186c1</code>가 바로 그 값이다. * 이제 두 커밋을 부모 자식 관계로 속인다. <code>.git/info/grafts</code> 파일에 <code>자식 부모</code> 순으로 적어준다. {{{#!vim [gypark@www UseModKr]$ echo 92de4e3fdcd017fa0692069d3dcb57e93ab5bcec \ 65919c894b1e19183c380d27093b5a08089186c1 >> .git/info/grafts }}} * 제대로 연결되었는지 확인 {{{#!vim [gypark@www UseModKr]$ git log --pretty=oneline ... 0be974ced4a7ab8212142666c321cbd66b170584 SlashLinks 옵션을 1로 켜고 관련 변수들을 절대 경로 92de4e3fdcd017fa0692069d3dcb57e93ab5bcec utf-8로 저장 <-- ext2.* 버전의 첫 커밋 65919c894b1e19183c380d27093b5a08089186c1 *** empty log message *** <-- ext1.* 버전의 마지막 커밋 8a90c0f4c323d44481184d97e42b3de5422ac4ed index 매크로 수정 - 인쇄할 때 인덱스 넘버를 출력하 ... }}} ** 성공! * grafts파일에 적어둔 현재 상태는 로컬저장소에서만 적용된다. 이걸 github 등에 Push를 하려면 실제로 커밋을 변경해주어야 한다<footnote("Pro Git"을 읽어봐도 그렇고 github 등을 읽어봐도 그렇고, 일단 외부에 push해서 남이 가져간 커밋을 나중에 고치는 건 절대로 피해야 할 일이라고 하니 주의)> ** <code>git filger-branch</code> 명령으로 커밋 내역 전체를 훑으면서 수정 ** 수정이 끝나면 grafts 파일은 삭제 {{{#!vim $ git filter-branch --tag-name-filter cat -- --all $ rm .git/info/grafts }}} * 끝났다. 위 과정 중에서, '''이전 저장소를 가져오는 부분'''의 더 깔끔한 방법: * [[#concat|두 저장소를 잇기]]절에 링크한 스택오버플로우의 글 참고. ext1.* 버전의 저장소를 fetch하면 되는 거였다. {{{#!vim [gypark@www UseModKr]$ git fetch ../testwiki.git master:old-history }}} ** 위와 같이, ext1.* 버전만 담긴 저장소를 fetch해 오면서 <code>old-history</code> 브랜치라 이름 붙인다 ** 이제 grafts 파일을 작성할 때, ext1.*버전의 마지막 커밋은 old-history가 가리키고 있으니 이것의 SHA값을 얻으면 된다. {{{#!vim $ git rev-parse old-history 65919c894b1e19183c380d27093b5a08089186c1 }}} 최종 결과물: * https://github.com/gypark/UseModKr - github에 업로드 == # 한글 파일,폴더명 표기 문제 == [http://kldp.org/node/132431 msysgit 으로 윈도우에서 git을 쓸 때 한글로 된 파일,폴더명이 깨져서 나오는 문제 | KLDP] - 이게 꽤나 불편함 Upload:git_korean.png KLDP의 답글을 보고 1.7.10을 설치했는데, 이 문제는 해결되지 않고 오히려 bash 창에서 한글 입력이 안 되고 기존 한글 폴더명들이 죄다 git status에서 삭제된 걸로 나오는 등 상황이 악화되었다. 1.7.8로 부랴부랴 다운그레이드. 현재 해결책 모름. 중간 정리: http://kldp.org/node/132431#comment-584574 으윽, 나중에 발견했는데 이건 리눅스에서도 마찬가지였으며, <code>core.quotepath</code> 옵션이 있어서 이걸 false로 해주면 안 깨지는 거였다. (윈도우에서는 여전히 문제가 좀 있지만) == # 출력을 무조건 cp949 로 변환 == 앞 섹션의 파일명 문제도 그렇고, UTF-8로 인코딩된 문서를 윈도우 명령 프롬프트 창에서 diff 를 보거나 (또는 반대로 euc-kr 문서를 리눅스에서 보거나) 등등 할 때마다 글자가 깨지니까, 그냥 필터를 하나 만들어서 보기로 함(이 코드 자체는 뭐 git에서만 쓰는 게 아니라 범용이지만) {{{#!vim perl #!/usr/bin/env perl # git diff 의 출력을 받아서 인코딩을 변환하여 출력 # 예: git diff --color | cat_encode.pl use strict; use warnings; use Encode; use Encode::Guess; my $pat_color = qr/(?:\e\[[;\d]*?m)/; my @ansi = (); my $output_encoding = 'cp949'; while ( my $line = <> ) { chomp $line; # ANSI 색상지정 코드를 일단 제거 $line =~ s/($pat_color)/save_ansi($1)/eg; my $enc = guess_encoding( $line, qw/cp949/ ); if ( not ref($enc) ) { print "!!! ", $line, "\n"; next; } my $str = encode($output_encoding, $enc->decode($line)); # ANSI 코드 복원 $str =~ s/___ansicode\((\d+)\)___/$ansi[$1]/eg; print $str, "\n"; } sub save_ansi { return '' unless ( -t STDOUT); my $ansi = shift; push @ansi, $ansi; return "___ansicode($#ansi)___"; } }}} * 코드만 따로 링크: https://gist.github.com/2412176 그러면 <code>git status | cat_encode.pl</code> 등과 같이 쓸 수 있는데, 이번엔 뭐가 문제냐 하면 git 에서 출력을 할 때, 터미널로 출력을 안 하는 경우는 ANSI 컬러 코드를 출력하지 않아서 출력이 한 가지 색상으로만 나온다는 점이다(컬러 설정 값이 auto일 때). 이걸 또 손봐야 한다. * diff 의 경우는 옵션으로 <code>--color=always</code>를 주거나, 설정 파일에 <code>color.diff = always</code>로 지정 가능 * status 는 실행할 때 옵션을 안 받아서, 설정 파일에 <code>color.status = always</code> * 뭐 이런 식으로, 한글도 깨지지 않았으면 좋겠고 컬러도 적용되었으면 좋겠다 싶으면 설정을 바꿔주면 되는데... 또 문제가 있어서ㅋ 출력을 파일로 리다이렉션할 때도 컬러코드가 끼어 버린다 -ㅅ-; 어째서 <code>--color</code> 옵션을 받는 명령이 있고 안 받는 명령이 있는 거냐... (cat_encode.pl을 거치면 터미널로 나올때만 컬러코드가 나오도록 해놓긴 했음) 그리고 매번 파이프를 쓰기 귀찮으니 alias 설정을 할 수도 있겠다. * status 같은 경우는 항상 다른 인자 없이 git status 로만 쓰니까 <code>alias.st = !git status | cat_encode.pl</code> 이렇게 해 버리면 됨 * diff 는 좀 다른게, git diff 뒤에 특정 파일 이름이나 커밋 이름 등 인자를 주는 경우가 있어서 위처럼은 곤란하고, 그냥 <code>alias.df = diff --color</code>로 해서 컬러를 강제로 켜는 정도로 타협 == # 복잡해져서 별도 페이지로 분리한 내용들 == === # 브랜치 === [[/Branch]] === # git rebase === [[/Rebase]] === # git reset === [[/Reset]] [[/ResetDemystified번역]] === # 복구 === [[/복구]] === # 서브프로젝트 === [[/서브프로젝트]] === # 그 외, 이럴 땐 이렇게 === [[/이럴땐이렇게]] [[/저장소병합]] == # 기타 == [[/작업흐름]] - [[UseModWiki소스수정]]에 git을 쓰는 예 [http://longair.net/blog/2011/02/27/an-asymmetry-between-git-pull-and-git-push/ An asymmetry between git pull and push « Mark’s Blog] [http://blog.doortts.com/141 여름으로 가는 문 - 번역: 서브버전 사용자를 위한 머큐리얼(mercurial)이전 가이드] * [http://surpreem.wordpress.com/2011/05/16/hg-init-a-mercurial-tutorial-introduction/ Hg Init: a Mercurial tutorial – Introduction « The dream of super surplus power] - 이쪽은 나머지 챕터도 다 번역되어 있음 [http://marklodato.github.com/visual-git-guide/index-ko.html A Visual Git Reference] [http://stackoverflow.com/questions/457927/git-workflow-and-rebase-vs-merge-questions version control - git workflow and rebase vs merge questions - Stack Overflow] [http://eagain.net/articles/git-for-computer-scientists/ Git for Computer Scientists] [http://dogfeet.github.com/articles/2012/git-translate-flow.html dogfeet - Git:번역 Workflow] [http://nolboo.github.io/blog/2013/10/06/github-for-beginner/ 완전 초보를 위한 깃허브] [http://blogs.atlassian.com/2014/06/happened-git-2-0-full-goodies/ It happened: Git 2.0 is here and it's full of goodies - Atlassian Blogs] [https://github.com/msysgit/msysgit/wiki/Git-for-Windows-Unicode-Support Git for Windows Unicode Support · msysgit/msysgit Wiki · GitHub] - 새 PC에서 지금 파일명 때문에 난리가 났음. [http://marklodato.github.io/visual-git-guide/index-ko.html A Visual Git Reference] [https://git-scm.com/book/ko/v2/Git%EA%B3%BC-%EC%97%AC%ED%83%80-%EB%B2%84%EC%A0%84-%EA%B4%80%EB%A6%AC-%EC%8B%9C%EC%8A%A4%ED%85%9C-Git%3A-%EB%B2%94%EC%9A%A9-Client#_git_svn Git과 Subversion] Git에서 subversion 저장소를 사용하여 pull, push하기 [https://stackoverflow.com/questions/7251477/what-are-the-differences-between-double-dot-and-triple-dot-in-git-dif/46345364 git diff와 git log에서 ..와 ...] == # [#unicode|git version 2.6.2 에서의 한글 사용] == 2015년 10월. 집에서 쓰는 데스크탑을 새로 구입하고 윈도우10을 설치하면서 git도 새로 설치하는데, 버전이 바뀌면서 한글 관련해서 여러가지가 바뀌었다. * 일단 git 1.7.10부터 파일명에 ASCII 이외의 문자가 있는 경우를 지원한다고 함 * 기존 msysgit 이 [https://git-for-windows.github.io/ Git for Windows]이 되었고, 잘은 모르겠지만 이 윈도우용 git을 개발하기 위한 환경으로서 msysgit이 남아 있는 듯. * 명령 프롬프트 창 말고 mintty란 터미널을 제공한다. (설치할 때 그냥 명령 프롬프트 창을 쓰도록 선택할 수도 있음) 이게 꽤 깔끔하고 괜찮아서 굳이 ckw 같은 다른 터미널 프로그램을 찾지 않아도 될 듯함 전체적으로, 기존의 각종 번잡한 설정을 추가하지 않고서도 훨씬 편하게 한글을 사용할 수 있다. === # 설치 === 설치할 때 특별히 기본값 대신 설정해준 것들: * git을 git bash에서만 사용하는 게 아니라 명령 프롬프트 창에서도 쓰도록 함 (두번째 옵션) ** 시스템 환경변수 <code>path</code>에 <code>C:\Program Files\Git\cmd</code>가 추가됨 * [[SSH]] 키 관리를 openSSH가 아니라 [[PuTTY]]의 <code>plink.exe</code> 를 쓰도록 함 ** github 등에 접속할 때 매번 ssh 키 passphrase를 입력하기가 귀찮은데, 기존에는 리눅스에서 쓰던 스크립트를 그대로 <code>.bashrc</code> 파일에 복사해서, 윈도 부팅 후 처음 git bash를 띄울 때 <code>ssh-agent</code>를 띄우도록 하였었음. ([[SSH]] 참고) ** 저 방법도 별 문제는 없는데, 그냥 GUI가 아니고 실행되고 있는 걸 눈으로 보기 힘들고(작업 관리자에서 프로세스 목록을 봐야함) 다른 프로그램들과 공유가 안 되는 게 불만 ** plink를 쓰도록 하면 시스템 환경변수 <code>GIT_SSH</code>와 <code>SVN_SSH</code>가 생기고 값이 <code>D:\Local\putty_0.65\PLINK.EXE</code>로 설정됨 ** 이제 PuTTY에 딸려있는 pageant를 실행해서 키를 등록해주면 git bash, putty, source tree 등이 다 이걸 사용해서 접속할 수 있다. *** 알고보니 openSSH에서 사용하는 <code>~/.id_rsa</code> 키는 pageant에서 바로 쓸 수가 없어서 새로 만들어줘야 하더라. puttygen.exe에서 기존 openSSH키를 Load하여 가져온 다음 변환해서 .ppk 파일로 저장하여 쓰면 된다. === # 터미널에서 한글 처리 === git bash 를 띄워보면... '''한글이 그냥 잘 되는 것 같다''' (아직 많이 써 본 게 아니라서 확신은 못하지만) * <code>LANG</code> 환경변수는 <code>ko_KR.UTF-8</code>로 세팅되어 있음 * <code>ls</code> 파일 목록을 보면 한글로 된 파일이름이 잘 나온다. * <code>grep 텍스트 *</code> 처럼 검색을 해도 잘 나온다. 즉 터미널 창에서 입력도 잘 된다. 저 텍스트는 UTF-8로 저장된 경우만 검색에 걸린다. * <code>touch 파일.txt</code>, <code>ls > 리스트.txt</code> 등으로 이름에 한글이 들어간 파일을 만들어 보았다. 그래도 잘 된다. * 이렇게 생성된 한글이름 파일들은 탐색기에서도 정상적으로 잘 보인다. 명령프롬프트창에 들어가서 봐도 문제없다. ** 그런데 NTFS가 아니라 FAT32 등의 파일 시스템을 쓰는 곳에서 만들 때는 어떻게 될지 모르겠다. USB 메모리 등에 해봐야... * <code>less</code>의 출력도 문제없음 === # git에서의 한글 처리 === 일단 파일명의 non-ASCII 캐릭터들을 <code>\숫자</code> 형태로 변환하지 않도록 옵션을 주자. {{{#!vim text git config --global core.quotepath off }}} 이제 기존 저장소에 가서 <code>git status</code>를 했더니... {{{#!vim text On branch master Your branch is up-to-date with 'origin/master'. Changes not staged for commit: (use "git add/rm <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) deleted: %$@%$@%@.txt <-- 깨진 글자 Untracked files: (use "git add <file>..." to include in what will be committed) 한글이름.txt no changes added to commit (use "git add" and/or "git commit -a") }}} 이렇게 한글이름 파일들은 전부 stage와 untracked에 동시에 나온다. stage에서는 글자가 와장창 깨진 이름으로 나오면서 지워진 걸로 나온다. git이 기존에 저장한 파일명과 현재 파일명을 서로 다른 이름으로 해석하고 있는 눈치이다. 이 깨진 파일명을 어떻게 수작업으로 하려고 해도, 그 이름의 파일을 찾지 못하여서 not match 어쩌고 하면서 아무것도 안 된다. 그래서 그냥 지금까지의 이력을 날려버리고 저장소를 새로 시작해야 하는가 했는데, 찾아보니 이와 관련한 문서가 있음 === # 기존 저장소 이전 === [https://github.com/msysgit/msysgit/wiki/Git-for-Windows-Unicode-Support Git for Windows Unicode Support · msysgit/msysgit Wiki · GitHub] 이 글에 "Migrating old Git for Windows repositories" 절을 참고한다. 1. 일단 저장소를 untracked 파일이 없는 깨끗한 상태로 만든다. * 1.7.10 이전 버전의 git이 있다면 그 git을 사용 {{{ /c/git1.7.9/bin/git clean -f && /c/git1.7.9/bin/git reset --hard }}} ** <code>git clean</code>은 untracked 상태의 파일들을 지워버린다. 혹시 그게 지우면 안 될 파일일지 모르니 일단 저장소를 백업해놓고 하자. ** 구버전의 git.exe 만 있다고 동작하지는 않는다. 내 경우는 기존 PC에 설치된 git 디렉토리를 통채로 가져와서 사용했다. * 이전 버전의 git이 없다면, 현재 버전의 git을 쓸 수도 있긴 하다. (비추) {{{ git clean -f && git reset --hard }}} ** 그런데 이렇게 하면 저장소의 상태가 어떻게 되냐 하면, 한글이름 파일들 각각마다 파일명이 깨진 글자로 된 파일들이 하나씩 짝을 이뤄 생겨난다. 이제 그런 것들을 일일이 찾아서 지워야 한다. 힘들더라. * 내가 해보니 어쨌거나 저장소를 clean 상태로 두기만 하면 되는 거라서, untracked 파일이 현재 없다면 이 1번 과정을 거치지 않아도 되는 것 같다. 나는 그냥 <code>.gitignore</code> 파일에 넣어버렸는데 별 문제 없었다. 2. 기존에 저장된 인덱스를 삭제하고, 파일들을 전부 새로 추가한다. {{{ git rm -rf --cached \* && git add --all }}} * 결국은 파일을 지우고 새로 <code>add</code>하고 있기 때문에... 특정한 파일에 대해 커밋 로그를 보려고 <code>git log -- 파일명</code>하면 한글 이름 파일의 경우는 과거 로그나 나오지 않게 된다. 이건 꽤 아쉽다. (어떤 파일은 나오고 어떤 파일은 안 나오는데 이런 차이가 나는 이유를 모르겠다) 3. <code>git status</code>를 해 보면 "깨진파일명 => 한글파일명" 상태로 이름이 바뀌어서 커밋 대기중인 상태로 나오는 거 확인한 후 커밋. {{{ git commit -m "UTF-8 conversion" }}} === # 시작 디렉토리 === 터미널로 ckw.exe 를 쓸 때는 시작 디렉토리를 지정할 수 있었는데 mintty에서 git-bash.exe 를 띄우는 현재 상황에서는 모르겠다. <code>~/.bashrc</code> 파일에다가 <code>cd /d/git</code> 같은 식으로 적어주어 해결 -_- === # 그 외 === 위 과정까지 거치고 나면, 그 다음은 중간중간에 다시 한글이 깨져서 어라 싶었던 경우가 있는데, git을 새로 설치하고 기존에 했던 각종 한글관련 설정을 하지 않은 상태에서 다시 재현하려고 하니 잘 되지 않는다. 아마 뭔가 기존 설정값이 문제였던 듯. 어쨌거나 1.7.9나 그 이전 버전을 쓸 때에 비하면 훨씬 터미널 환경에서 쓰기 편해진 느낌이다. 그런데 웬만하면 source tree 같은 걸 쓰는 게 나아보이기도. 나는 계속 리눅스나 맥의 커맨드 라인에서 쓰다보니 GUI가 낯설어서 그렇지만... == # Comments == <div class="comments"> 아 너무 좋은 글입니다. \\ msysgit 에잇하고 포기하고 있었는데 다시 도전해봐야 겠네요. \\ 잘보겠습니다. 감사합니다. <mysign(박창우,2012-4-12 10:26 pm)> : 사실 지금도 diff 등을 볼때 UTF-8 인코딩된 소스코드들의 한글이 와자작 깨져서 콘솔 창에서 못 보고 일일이 GUI툴을 띄우거나... 그래서 "에잇" 소리는 자주 나옵니다 ^^; <mysign([[Raymundo]],2012-4-12 10:42 pm)> win7 64 home premium eng 버전을 사용하고 있는데, \\ 이유는 모르겠지만 위에 설명하신대로는 실행이 안됩니다. \\ 다음 처럼 실행하니 되는 군요. \\ \\ "D:\local\ckw.exe" -e "C:\Program Files (x86)\Git\bin\sh.exe" -login -i <mysign(박창우,2012-5-2 9:25 am)> : 오홍, 저는 지금 윈XP 사용 중이라... 위에도 적어두겠습니다 감사합니다. <mysign([[Raymundo]],2012-5-2 2:16 pm)> 윈도에 git 설치하던 초반에 한글 관련해서 가장 도움이 되었던 내용입니다. \\ 종종 참조하곤 합니다. 감사합니다^^ <mysign(아폴로,2013-7-31 5:49 pm)> : 도움이 되었다니 저도 기분 좋네요. 근데 솔직히 윈도우에서 쓰려면 일단 한글 인코딩부터 시작해서 형편없는 명령프롬프트 창에... 그냥 gitk 같은 걸 쓰는 게 나을지도 모르겠어요 ^^; <mysign([[Raymundo]],2013-7-31 6:13 pm)> 유난히 이 페이지에 스팸이 많이 들어와서, 코멘트 입력창은 지움. <mysign([[Raymundo]],2015-10-2 3:26 pm)> ---- </div> ---- [[컴퓨터분류]]
Git
페이지로 돌아가기 |
다른 수정본 보기
![[첫화면으로]](/raymundo_logo.jpg){kind=logo}
Git 페이지의 소스 보기Git 페이지의 소스 보기