개발새발

프로 Git 한글책 출간

2013-05-20T15:00:00.000Z

Pro Git 한글 번역이 인사이트의 도움을 받아 종이책으로 프로 Git 으로 출간되었습니다. 학생분들은 도서관에 직장인은 도서구매부에 얼른얼른 구매 신청해주세요! ㅎㅎ

프로 Git 출간 이야기

이미 Pro Git의 한글 번역 전문이 이 블로그 및 github을 통해 오픈소스로 공개되어 있지만, 인사이트 출판사의 도움으로 종이책으로 출간되었습니다. 종이책으로 나올 수 있었던 뒷 이야기는 인사이트 블로그의 <프로 Git>, 이미 공개된 내용을 왜 책으로 만들었냐고요? 글을 통해 살펴보실 수 있습니다.

종이책으로 출간된 책의 기본 내용은 동일하지만 몇 번의 교정 과정을 더 거쳤고 이미지도 업데이트 되었으며 부록으로 미처 다루지 못한 몇 가지 내용을 더 담아두었습니다.

주요 오프라인이나 온라인 서점을 통해 구입하실 수 있구요 출간된 것은 4월 중순인데 이렇게 글로 소식을 올리는 것이 늦어졌습니다. ^{^}

또 다른 번역서, 데브옵스 출간 소식

또 하나, ‘프로 Git'에 이어 저희 팀원분이 번역한 데브옵스도 5월 말에 출간됩니다. 데브옵스에 대한 다양한 문제 상황과 해결법을 다루고 있어 관심있는 분께는 많은 도움이 되리라 생각합니다. 현재 예약판매 중이며 곧 온라인과 오프라인 서점에서 구입하실 수 있습니다.

git: password caching

2013-03-27T15:00:00.000Z

요즘은 뭐든 Smart한 시대인지라 http(s) 프로토콜도 Smart하지 않을 수 없다(Smart http). Pro Git에서는 http(s)가 Smart하지 않다고 설명하지만 그건 Pro Git이 출간되고 나서 만들어진 거라 책에는 내용이 빠져 있다. 이제는 ssh를 사용하든 http(s)를 사용하든 효율의 차이는 없다.

ssh는 회사 방화벽에서 막아버릴 수도 있고 익명접근도 허용하지 않지만, http(s)는 그런 게 없다. GitHub도 이제는 ssh가 아닌 http(s)가 기본이다(https 주소를 먼저 보여준다):

그런데 ssh는 인증서를 사용하면 ssh-agent를 사용하면 암호를 한 번만 입력할 수 있는데, http(s)에서는 Basic 인증을 통해서 인증하는지라 다른 메커니즘이 필요하다. 이 글은 GitHub help 페이지에 있는 Password Caching을 요약한 글이다.

Password Caching.

Git버전이 1.7.10 이상 돼야 한다. 그래야 이 기능을 사용할 수 있다.

나는 주로 ssh를 사용하므로 http(s)를 잘 사용하지 않는다. ssh에 익숙해져서 http(s)가 더 어색하다. 하지만, gist에서는 http(s)를 사용하는 것이 편하다. GitHub이 Gist에서는 git 프로토콜 주소를 안내하지 않고 있다:

화면의 주소는 다음과 같은 형태다:

https://gist.github.com/xxxxxxxxxxxxxxxxxxxx.git

ssh 프로토콜로도 사용할 수 있긴 하다. 단지 복사해서 붙여 넣을 수 없을 뿐이다:

git@gist.github.com:xxxxxxxxxxxxxxxxxxxx.git

gist는 git을 이용하지만 전문 버전관리 도구가 아니라 프로토타이핑 도구라서 http(s) 프로토콜만으로도 충분할 수 있다. 그래도 명령을 실행할 때마다 암호를 입력하는 일은 좀 불편하다. http(s)에도 ssh처럼 사용할 수 있는 매우 편리한 방법이 있다.

Linux

다음과 같이 설정하면 한번 입력한 암호가 저장된다:

% git config --global credential.helper cache

기본적으로 15분 저장해주는데 다음과 같이 기간을 수정할 수 있다:

% git config --global credential.helper 'cache --timeout=3600'

‘ssh-agent'로 하는 것과 거의 비슷하다.

Mac

Mac에서는 'osxkeychain credential helper'라는 게 있어서 ssh처럼 keychain을 사용할 수 있다.

먼저 osxkeychain이 잘 동작하는지 확인하고:

% git credential-osxkeychain
Usage: git credential-osxkeychain <get|store|erase>

설치돼 있지 않으면 아래와 같이 설치한다:

% git credential-osxkeychain
git: 'credential-osxkeychain' is not a git command. See 'git --help'.

% curl -s -O http://github-media-downloads.s3.amazonaws.com/osx/git-credential-osxkeychain
% chmod u+x git-credential-osxkeychain
% sudo mv git-credential-osxkeychain `dirname \`which git\``

'credential helper'로 osxkeychain을 사용할 것이라고 알린다.:

% git config --global credential.helper osxkeychain

이제 ssh를 사용할 때는 ssh 인증서가 사용되고 http(s)를 사용할 때는 'osxkeychain credential helper'가 사용된다.

이렇게 설정하면 CLI뿐만 아니라 SourceTree같은 GUI에서도 매번 암호를 입력하지 않을 수 있다.

Windows

git-credential-winstore를 내려받아서 실행경로에 넣고 한번 실행해준다. 그러면 msysgit 에서 잘 사용할 수 있다. 'GitHub for Windows'에는 이미 포함돼 있어서 별도로 설치할 필요가 없다.

Windows XP에서는 SourceTree를 설치할 수 없어서 확인하지 못했다.

mac: java-web-start

2013-03-07T15:00:00.000Z

언제부터 안되더라? 왜 안되더라? 그런건 잘 모르겠고 Mac에서는 Java Web Start가 그냥 실행되지 않는다. Apple이 막은 건데, Oracle이 미운 이유는 뭘까! 아무튼 다시 켜는 방법이 있다.

Java web start

윈도에서 처럼 매끄럽게 브라우저 안에서 Java App이 실행되지 않더라도 jnlp 파일을 다운로드 받아서 javaws 명령으로 실행시키면 실행해야 하는데 다음과 같은 에러를 내뱉는다:

% javaws my.jnlp
Java Web Start splash screen process exiting ...
Can not find message file: No such file or directory

Google님께 물어보면 Java7을 설치하라는 얘기가 많다. 그래서 설치하고 이것 저것 해봤는데도 됐다가 안됐다가 했다. 자세한 히스토리는 알고 싶지 않았고 그냥 실행만 됐으면 했는데, 그래도 그냥 Java7을 설치했었다. Oracle Java7을 설치하라고 하니 왠지 내 Mac을 욕보이는 것 같았지만 그냥 설치했다.

어짜피 안돼서 Java7을 삭제했는데 Mac이 먹통ㅜㅜ. Mac까지 다시 설치해야 하나 싶었는데 이유는 모르겠지만 복구 됐다(야호!). 욕하고 싶은 상대가 Apple이 아닌 Oracle인건 왜일까!

아래와 같이 파일을 열고:

% sudo vi /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist

주석처리를 좀 하고:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<!--
  <key>JavaWebComponentVersionMinimum</key>
  <string>1.6.0_41-b02-446</string>
-->
  <key>LastModification</key>
  <string>Mon, 04 Mar 2013 21:47:02 GMT</string>
  <key>PlugInBlacklist</key>
  <dict>
    <key>10</key>
    <dict>
      <key>com.macromedia.Flash Player.plugin</key>
      <dict>
        <key>MinimumPlugInBundleVersion</key>
        <string>11.6.602.171</string>
      </dict>
<!--
      <key>com.oracle.java.JavaAppletPlugin</key>
      <dict>
        <key>MinimumPlugInBundleVersion</key>
        <string>1.7.15.04</string>
      </dict>
-->
    </dict>
  </dict>
  <key>Version</key>
  <integer>2033</integer>
</dict>
</plist>

리부팅한다. 그리고 아래와 같이 실행한다:

% javaws my.jnlp

Apple이 Flash와 Java Applet을 BlackList로까지 분류하고 있는 줄은 몰랐다.

그리고 Mac update를 하면 다시 Disable된다. Disable되면 jre가 설치돼 있는데도 불구하고 javaws를 실행했을 때 아래와 같은 에러를 뱉는다:

% javaws my.jnlp
No Java runtime present, requesting install.
Unable to locate a Java Runtime to invoke.

아래와 같이 실행하면 다시 javaws를 사용할 수 있다:

sudo ln -sf /System/Library/Frameworks/JavaVM.framework/Commands/javaws /usr/bin/javaws

수동으로 다시 disable하고 싶으면 아래와 같이 실행한다:

% sudo ln -sf /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/javaws /usr/bin/javaws

grunt: node-coffee 템플릿

2013-02-20T15:00:00.000Z

@Outsideris님의 자바스크립트 빌드 도구 Grunt와 Grunt에 사용자 템플릿 추가하기를 읽고 node-coffee 템플릿을 만들었다. @docpad 덕에 coffeescript에 익숙해졌고 항상 Compile해서 실행하기만 하면 디버그도 할 수 있기 때문에 node를 사용할 때는 coffee를 사용하려고 하는 편이다. 그동안 make를 사용해서 좀 불편했었는데, grunt를 적용하니 정말 편하다. 좀 더 편하려고 Coffeescript에 Mocha를 기본으로 하는 템플릿을 하나 만들었다.

grunt 0.4

갑자기 0.4 버전이 배포되는 바람에 @Outsideris님의 글이 내용이 틀리게 됐다. 하지만 정리가 잘돼 있어서 grunt를 이해하기에는 여전히 좋은 글이다.

@Outsideris님의 글을 읽고 0.3 버전용 node-coffee를 만들었다가 나중에 글을 써야지 하고 있었는데, 0.4가 나와 버렸다. upgrading-from-0.3-to-0.4을 잘 읽고 적용하는 게 좋다. 나는 길어서 대충 읽었다가 삽질을 좀 했다. 다 읽기 귀찮으면 새 템플릿으로 만든 코드를 좀 읽어보고 시작하는 것이 시간을 절약해줄 것 같다.

node-coffee 템플릿

이 템플릿은 특징을 요약하면 아래와 같다:

Coffeescript
- Gruntfile.coffee
- /src/lib/**/*.coffee를 /out/lib/**/*.js로 컴파일
- /src/test/**/*.coffee를 /out/test/**/*.js로 컴파일
- coffeelint
Javascript
- /src/lib/**/*.js를 /out/lib/**/*.js로 복사
- /src/test/**/*.js를 /out/test/**/*.js로 복사
- jshint 그대로 포함
Mocha + Should로 변경

그 외는 node 템플릿을 수정한 것이기 때문에 node 템플릿과 같다.

사용법

다음과 같이 설치한다:

git clone git@github.com:pismute/grunt-init-node-coffee.git ~/.grunt-init/node-coffee

grunt-init이 설치된 상태에서 다음과 같이 프로젝트를 만든다:

mkdir my-project
cd my-project
grunt-init node-coffee

그와 그녀의 tryios

2013-01-19T15:00:00.000Z

codeschool에 tryios가 올라오자마자 노리고 있었다. 왠지 재미도 있고 쉬울 것 같았다. 이 글은 iOS 초보인 그와 코딩 초보인 그녀가 함께 tryios를 해보고 난 후기다.

tryios

이 강의는 제목에서처럼 정말 iOS를 소개하는 수준의 강의다. @greggpollack 선생님이 천천히 쉬운 영어로 설명해주는 것 같지만 뭐라고 말하는지는 들을 수 없다. 내용이 쉬워서 슬라이드로도 충분하긴 하지만 그래도 영어를 알아듣고 싶다.

무료인 codecademy보다 퀄리티가 높을 거라고는 생각했지만 이렇게 친절할 줄은 생각도 못했다. 처음 접하는 사람이 쉽게 따라 할 수 있도록 기초적인 커리큘럼에 필요한 내용만 가르쳐준다. 거기다가 동영상도 공을 들인 티가 난다. 슬라이드도 아주 예쁘다.

이 강의를 만드는데 무려 12명이나 참여했다:

‘Mr. Higgie'라는 캐릭터 까지 있다:

설명을 듣고, 코딩해서, 바로 검사하는 구조는 너무 매력적인 학습방법이다. Coursera의 Scala 강의도 그런 방식이였는데 굉장히 잼있었다. 무엇보다 바로 내가 틀렸는지 알 수 있기 때문에 될 때까지 버티면 정말 된다.

Gamification이 잘 돼있어서 강의를 하나씩 끝날 때 마다 뱃지를 준다:

http://beta.openbadges.org/ 에 연계도 된다. Open Badges라는 거 처음 봤는데, 뭔지 모르겠다.

Coursera Scala 강의에서는 오덕스키 선생님의 사인이 든 수료증도 줬는데 @greggpollack 선생님의 사인이든 수료증을 별도로 주지 않는다. 하지만 'Report Card'라는 게 있다:

이 'Report Card'는 공개할 수도 있고 비공개로 설정할 수도 있다. 하지만 타인의 Report Card를 보는 페이지는 찾지 못했다.

CodeSchool은 한달에 $25 단위로 결제해야 한다. $25 결제하면 원하는 대로 강의를 들을 수 있다. 무료 강의도 몇개 있어서 trygit같은 것을 무료로 해볼 수 있다.

뭔가 처음이라면 codeschool의 강의를 들어보는 게 좋겠다. 유료지만 한달에 $25이 아깝지 않다.

Kickstarter에서 $152,912를 펀딩받아 제작됐다고 한다(http://www.codeschool.com/2012). http://macminicolo.net/ 사람들이 만든 것 같은데(추측임), 강의 처음에 나오는 광고도 귀엽다. 앞으로도 재미난 iOS 강의가 많을 것 같아 기대된다.

code TV

CodeSchool은 Code TV라는 podcast도 제공한다. podcast 링크는 iTunes에서 찾을 수 있다. 좀 잼있어 보이는 강의가 몇개 있다. 영어를 못 들으니 영어 자막을 함께 제공해 줬으면 좋겠는데 영어 자막을 제공하지는 않는다.

수료

tryios를 수료하면 3가지 보상을 준다. 일단 $5에 이르는 CodeSchool Cash와 'iOS SDK Development'라는 책의 25% 할인권 그리고 TinkerLearn의 50% 할인권을 준다. 지원해주는 회사가 있으면 재밌게 공부도하고 수익 남는ㅋㅋㅋ:

TinkerLearn은 무료 Lesson만 다운받았는데 해당 Lesson과 관련된 pdf와 샘플 코드가 들어 있다. tryios를 끝낸 후 다음에 뭘해야 할지 고민할 필요도 없다:

그녀

그녀의 개발툴은 Illustrator와 Photoshop으로 프로그래밍은 잘 모른다. 디자이너도 코드를 읽을 줄 알아야 한다는 드립을 한 5년간 쳤는데, 드디어 일진보 했다.

내가 그녀에게 친 뻥은 아래와 같다:

인생은 학습이다. 뭘 배우는지 중요치 않다. 뭐든 배우는 거다.
실무자가 의사 결정을 직접 해야 작업 속도가 빠르고 퀄리티도 높다. 소프트웨어 디자인을 한다면 소프트웨어에서 디자인을 어떻게 표현하는지 사람들이 어떻게 작업하는지 알아야 한다.
결정권이 없는 실무자는 우울해진다. 동료를 위해 디자인과 관계된 실무를 익혀라.

그녀에 대답은 대체로 아래와 같았다:

너부터 디자인을 배워라.
소프트웨어 싫다.
동료가 없다.

그렇게 줄다리기를 하다가 CodeSchool 덕택에 함께 공부를 해보게 됐다.

뭐든 상관 없지만, iOS를 배워보기로 했다. iOS, web, Android를 제안했는데 그녀는 iOS를 골랐다. iPhone의 완성도는 역시 너무 매력적이다.

tryios를 시작하기 전에 그녀는 Objective-C를 좀 먼저 읽었다. 분명 제대로 공부를 하고 있다면 질문이 많았을 텐데 질문이 많지 않은 거로 봐서 멘붕 상태에 있다는 걸 알 수 있었다. 그녀는 tryios 강의를 수료한 지금도 멘붕 상태다.

들리지도 않는 동영상 교재를 끝까지 듣고, 처음보는 외계어로 가득찬 슬라이드를 끝까지 감내한 그녀에게 경의를 표한다.

총 6 챕터로 구성된 강의는 매 챕터마다 3~4시간 가량 걸렸다. tryios는 아주 기본적인 내용만 다루기 때문에 하루 정도면 충분하다. 나는 좀 불친절한 성격이라 그녀가 묻는 질문에만 대답해서 오래걸렸다.

내 느낌은 이렇다:

내가 그녀라면 인내할 수 있었을까? 훌륭하다. 그녀는 이왕 결재한 거라고 하면서 Functional HTML5 & CSS3와 CSS Cross-Country 강의도 시작했다:

tryios 강의를 끝내고 받은 퀘스트 보상때문에 나도 이 두 강의를 시작했다. 찬찬히 CodeSchool의 강의를 전부 해보려한다.

영어

영어라는 장벽이 없었으면 나도 그녀도 좀 더 쉽게 따라 했을 것 같다. 영어로 표현된 외계어로 가득찬 자료를 끝까지 참아줘서 고맙다. 그덕에 나도 많은 것을 배웠다.

CodeSchool 강의 중에서는 영어자막을 제공하는 강의도 있다. tryios는 제공하지 않았는데 Functional HTML5 & CSS3와 CSS Cross-Country는 영어자막이 있다.

영어가 되는 사람들은 좋겠다. 쉽고 재밌는 학습 도구가 많아서 좋겠다. 글래머 금발이랑 코딩할 수 있어서 좋겠다. 앞으로는 영어를 좀 더 to-the-core하게 해서 그런 삶을 살아야 겠다.

Git: GitHub secrets

2012-12-29T00:00:00.000Z

이글은 @holman님이 싱가폴에서 열린 RedDotRubyConf에서 발표한 Git and GitHub Secrets에 설명을 달았다. 내용이 길어서 둘로 나눴는데 이 글은 GitHub Secetets 부분을 정리한 글이다. Git Secrets은 다른 글에서 정리한다.

이 글을 정리하면서 그림을 많이 삽입하지 않았다. GitHub Secrets 부분은 그림이 너무 많아서 생략했다. 이 글을 읽고서 슬라이드를 한번 보는게 좋을 것 같다.

숨겨진 기능

GitHub은 단순함을 추구한다. 그래서 GitHub에는 기능이 많은 데도 불구하고 굳이 화면에 보여주지 않는다.

.patch, .diff

커밋 URL 뒤에 .patch나 .diff 붙이면 해당 포멧의 파일이 나온다. 정확하게는 ‘Compare View, Pull Requests, Commit Pages’ 화면에서 사용할 수 있다.

공백문자는 무시하고 diff를 보여준다.

diff URL끝에 ?w=1를 붙이면 공백문자를 무시한 결과를 보여준다.

SVN 클라이언트도 지원.

‘SVN/Git 서비스 레이어'가 있어서 SVN 요청을 Git 요청으로 변환해준다.

당연히 Git 클라이언트를 사용할 수 있지만:

$ git clone https://github.com/dogfeet/dogit.git

SVN 클라이언트도 사용할 수 있다:

$ svn checkout https://github.com/dogfeet/dogit.git

SSH & HTTP => HTTP & SSH

GitHub은 기본 프로토콜을 SSH에서 HTTP로 바꿨다. 원래 HTTP 프로토콜을 사용하는 방식은 성능이 후져서 SSH를 권장했는데 이제 SmartHTTP 덕택에 HTTP도 효율적이다.

원래 SSH를 먼저 보여줬었지만:

지금은 HTTP를 먼저 보여준다:

이제 HTTP도 효율적이기 때문에 1) 회사 방화벽 뒤에서도 맘껏 GitHub을 즐길 수 있고 2) SSH Key를 사용하기 힘든 Windows 환경에서도 사용하기 쉬워졌다. SSH key없이도 암호를 메모리에 저장해서 사용할 수 있다. 이 방법은 git 1.7.10부터 사용할 수 있고 GitHub의 패스워드 캐싱하는 방법에 잘 설명돼 있다.

SmartHTTP

SmartHTTP는 git 1.6.6부터 지원한다. git 1.6.6은 2009년 말에 배포됐다.

Git은 개체를 'Packfile'이라는 덩어리에 묶어서 관리한다. 이전 버전에서는 사용자가 'Packfile'에 들어 있는 개체 한 개가 필요해도 Packfile을 통째로 전송해야 했다. 그래서 HTTP를 더미 프로토콜이라고 불렀다. 이제는 SmartHTTP가 있어서 'Packfile'에서 필요한 개체만 꺼내서 전송할 수 있다.

progit 책을 집필할 때에는 SmartHTTP가 없었기 때문에 이를 설명하지 않았다. SmartHTTP에 대해서 자세히 알아보려면 progit 9장과 Smart HTTP Transport를 읽는게 좋다.

URL에서 ’.git'은 생략해도 된다.

git clone https://github.com/holman/boom.git
git clone https://github.com/holman/boom

GitHub HD™

GitHub 페이지의 아이콘이 HD 벡터 아이콘이라서 계속 확대해도 깨지지 않는다.

Auditing

우리말로 하자면 ‘감사로그’ 쯤 되는 건데, GitHub에서 일어난 중요한 액션은 로그가 남는다:

https://github.com/settings/security

Octocat

@defunkt님이 에러페이지에 사용할 이미지를 찾다가 Istockphoto에서 싸게 산 이미지였는데 사람들이 좋아해서 지금은 GitHub의 마스코드가 됐다. 처음에는 아니였지만 지금은 GitHub이 저작권을 가지고 있다.

Octocat 스토리는 Quora에서 참고.

http://octodex.github.com/ 에 가면 Octocat 이미지가 많다.

git.io

GitHub용 URL Shortner이다. 작은 쉘 스크립트로 구현돼 있고 다음과 같이 사용한다.

$ gitio <url> <name>

Chrome Extension도 있다.

Linguist

저장소에 든 언어가 뭔지 찾아서 직접 그 저장소에서 개발된 파일만 추려서 ‘Syntax Highlighting'도 해준다. GitHub은 이 Linguist를 다음과 같은 걸 만들어 내는데 사용한다:

기능:

'Language Detection’ - 어떤 언어가 사용됐는지 찾는다.
‘Stats’ - 언어 통계를 알려준다.
‘Syntax Highlighting’ - Pygments를 사용한다.
‘Vendored Files’ - 저장소에 들어 있는 파일 중 다른 프로젝트에서 가져온 파일. ex) jquery.js
‘Generated file detection’ - 생성되는 파일을 알아서 제외한다.

email reply

이메일로 comments에 답변을 달 수 있다.

gist

단순히 코드 snippet을 공유하는 도구가 아니다. 코멘트, 스크린샷, 코드를 공유를 할 수 있기 때문에 프로토타이핑 도구로 사용하기에도 좋다. 개발자와 디자이너 모두에게 유용하다.

gist 자체가 git 저장소이기 때문에 clone할 수도 있다:

git clone git://gist.github.com/2720312

간단하게 만들어서 프로토타이핑을 해보기에 아주 좋다.

microgems.

Ruby Gem으로도 사용할 수 있는 것 같다. 나는 Ruby를 몰라서 알 수 없다.

http://jeffkreeftmeijer.com/2011/microgems-five-minute-rubygems/

Image View Mode

Gist에 이미지를 올리고 비교하면 비교해보기 좋게 나열해준다. 정말 쩐다. 데모 페이지에 가서 클릭해보자.

이 기능은 KaleidoScope같은 도구에서 있는 건데 GitHub도 된다. SourceTree같은 데서도 가능하면 좋겠다.

GitHub의 Behold: Image view modes에 잘 소개돼 있다.

Command Line GitHub - hub

hub라는 프로그램이 있다. Command Line에서 GitHub을 사용할 수 있는 명령이다. git + github 명령이라고 생각하면 된다. GitHub을 사용하면서 자동화한다면 꼭 필요한 툴이라고 생각된다. 나중에 따로 정리해야 겠다.

Keyboard Shortcuts

GitHub의 모든 페이지에서 ?를 누르면 그 페이지에서 사용할 수 있는 단축키를 보여준다.

Subscribing People

GitHub에서 글쓸때 @pismute쓰면 해당 사용자에게 알림이 간다. @org/team라는 팀 표현식도 있어서 팀 전체한테 노티를 줄수도 있다.

GitHub Flavored Markdown

GFM에 대한 설명도 있다.

Auto-Closing Issues

커밋메시지에 CLOSES/CLOSED/CLOSE #1나 FIXES/FIXED/FIX #1라고 쓰면 해당 이슈가 자동으로 닫힌다.

Commit by Author

GitHub의 커밋 페이지에서 ?author=holman 처럼 파라미터를 넘기면 해당 사용자의 커밋만 볼 수 있다:

https://github.com/progit/progit/commits/master?author=pismute

Branch-to-Branch

Pull Request는 브랜치 단위로 하는 거라는 얘기. 그래서 원 저장소가 아니라 Clone 저장소에도 Pull Request를 보낼 수 있다.

emoji!

GitHub에서 emoji 이모티콘을 사용할 수 있다. 사용할 수 있는 이모티콘은 http://www.emoji-cheat-sheet.com/ 에서 참고.

Link Linking

GitHub 페이지에서 파일 보기 화면에서 URL 뒤에 #L16을 붙이면 16라인이 노랗게 보인다. #L16-32를 붙이면 16라인부터 32라인까지 노랗게 보인다. 다른 사람과 코드에 대해 수다떨 때 어떤 라인에 대해서 얘기하는 건지 콕 집어 줄 수 있다.

Advanced Compare View

github.com/user/repo/compare/{range}과 같은 형식의 URL을 사용하면 되고 {range}부분에 다음과 같이 넣을 수 있다:

master@{1.day.ago}...master
master@{yesterday}...master
master@{2012-02-25}...master

아래와 같이 사용한다:

https://github.com/dogfeet/dogit/compare/master@{60.day.ago}…master

Git: git secrets

2012-12-19T00:00:00.000Z

이글은 @holman님이 싱가폴에서 열린 RedDotRubyConf에서 발표한 Git and GitHub Secrets에 설명을 달았다. 내용이 길어서 둘로 나눴는데 이 글은 Git Secetets부분을 정리한 글이다. GitHub Secrets은 다른 글에 정리한다.

Git은 명령과 옵션이 굉장히 많은데, 그 중에서 @holman님이 추천하는 쓸만한 것이라고 생각하면 되겠다.

Git secret

–allow-empty

파일없이 커밋할 수 있다:

$ git commit -m "LOOK AT ME TROLOLOL" --allow-empty

git log를 하면 아무내용없이 그냥 커밋 개체만 달랑 생긴다.

$ git log
commit 6eb28f645174fba20d819f40da4ca822c7c67b2a
Author: Changwoo Park <pismute@gmail.com>
Date:   Tue Nov 12 20:32:25 2012 +0900

    LOOK AT ME TROLOLOL

히스토리에 뭔가 표식을 남기고 싶을 때 유용하다.

Staging Hunk

파일에서 한 부분? 덩어리?를 Hunk라고 부른다. git add -p 명령으로 파일을 통째로 Staging Area에 넣는게 아니라 일정 부분만(hunk만) 골라서 넣는다.

자세한 설명은 @semtlnori님의 깔끔하게 커밋하기를 보자.

git show :/query

특정 질의가 들어간 커밋 중에서 가장 최근 커밋 하나를 찾아 준다. 로그를 분석할때 매우 유용하다. 커밋 메시지, 파일 이름, 파일 내용에서 찾는다.

git log 명령에도 있어서 git log :/query라고 실행해도 된다. :/query 만족하는 커밋을 골라서 보여준다.

go back

cd -라고 실행하면 이전 디렉토리로 되돌아 간다. cd명령 처럼 git checkout -라고 하면 이전 브랜치를 checkout한다.

merged branch

브랜치나 커밋이 다른 브랜치에 Merge됐는지 확인하는 명령들.

git branch --merged : 이미 다른 브랜치에 머지된 것만 보여준다.
git branch --no-merged : 아직 다른 브랜치에 머지되지 않는 것만 보여준다.
git branch --contains 838ad46 : 특정 커밋이 포함된 브랜치만 보여준다.

Content Copy

브랜치를 변경하지 않고도 다른 브랜치에 들어 있는 파일을 복사해 올 수 있다:

$ git checkout BRANCH -- path/to/file.rb

path/to/file.rb에 파일이 복사된다.

Reset과 Checkout은 비슷해보여서 구분하기 쉽지 않다. Checkout은 데이터베이스에서 뭔가를 꺼낼때 사용하는 명령이다. 옵션도 스냅샷과 파일이름 등 그와 관련된 옵션으로 구성돼있다. 반대로 Reset은 워킹 디렉토리, Staging Area, 브랜치 등을 스냅샷으로 Reset하는 명령이다.

이렇게 구분하면 쉽다. 데이터베이스에서 뭔가를 꺼낼때는 Checkout을 사용하고 그외는 Reset을 사용한다.

Reachable Commits

특정 브랜치에만 있는 커밋이 보고 싶을 때는 다음과 같이 한다:

git log branchA ^branchB

branchA에는 있고 branchB에는 없는 커밋을 보여준다.

FINDING LOST COMMITS

어떤 브랜치에도 들어 있지 않은 커밋을 보여준다. git의 커밋은 개체는 실제로 전부 immutable이라서 커밋을 수정하면 새로운 커밋 개체가 등록된다. 잘 못 수정했으면 아래 명령으로 커밋을 찾아서 복구한다:

$ git fsck --lost-found
Checking object directories: 100% (256/256), done.
dangling commit 4a7f2e89a480d3af0ccfdf71f76f4149f25fb0fb
dangling commit d3ad9f17532109d12084646c306e9d7748c2f791

어떤 브랜치에도 속하지 않은 커밋이 두 개있다.

DIFFSTATS

델타(diff)를 다 보여주는 게 기본인데 통계만 볼 수도 있다:

git diff HEAD^ --stat

BLAME

git blame은 기본적으로 어떤 라인을 누가 고쳤는지 확인하는 명령이다.

blame이니까

git blame은 기본적으로 어떤 라인을 어떤 새끼가 고쳤는지 확인하는 명령이다.

git blame -w

정말 내용을 수정한 새끼를 찾는다. 공백만 추가한 경우는 무시한다. git diff HEAD~ 명령으로 공백이 어디에 추가됐는지 보자:

히스토리를 보면 마지막에 “BBB"가 공백을 추가했다:

다음은 git blame -w의 결과다:

단순히 공백만 추가한 "BBB"는 무시된다. -w을 옵션을 빼고 git blame만 실행하면 공백만 추가한 "BBB"도 나온다.

git blame -M

해당 라인을 실질적으로 마지막에 수정한 사람을 보여준다. 이 옵션을 주면 같은 파일 내에서 단순히 라인을 옮긴 사람이 아니라 마지막으로 내용을 수정한 사람이 표시된다:

텍스트를 옮긴 후에 git blame 명령을 실행하면 다음과 같이 나온다:

-M 옵션을 추가하면 단순히 옮긴 사람이 아니라 원래 그 코드를 추가한 사람을 보여준다:

원래 의도는 측근 all.md 파일에서 친구 끼리, 가족 끼리 모아서 -M 옵션을 설명할 계획이였다. Git이 정확히 어떤 알고리즘을 사용하는 건지 나중에 살펴봐야 겠다.

git blame -C

-M와 비슷하게 실제로 마지막에 수정한 사람을 보여준다. 한 파일 내에서의 이동만 감지하는 것이 아니라. 같은 커밋에서의 다른 파일간 이동도 감지한다.

all.md라는 파일에서 친구는 friends.md라는 파일로 옮기고 가족은 family.md 파일로 옮겼다. 아래는 git blame -f family.md의 결과다:

-f는 원래 파일이름을 보여주는 옵션이다. git blame -fC family.md의 결과는 아래와 같다:

git blame -CC

-C 처럼 다른 파일에서 옮긴 것을 감지해주는데 해당 파일을 생성한 커밋내에서도 감지한다.

git blame -CCC

다른 파일에서 옮긴 것도 감지하는데 커밋을 가리지 않고 전체에서 찾는다.

MULTI-REMOTE FETCHES

원래는 하나씩 fetch해야 하지만 group을 만들어서 한번에 fetch할 수 있다.

$ git config remotes.mygroup 'remote1 remote2'
$ git fetch mygroup

A BETTER STATUS

status의 결과를 더 간략하게 볼 수 있다.

git status:

git status -sb:

WORD DIFFING

라인 단위로 비교하는 것이 아니라 단어 단위로 비교해서 볼 수 있다.

git diff HEAD^:

git diff HEAD^ --word-diff:

CONFIG: SPELLING

git comit이라고 실행하면 commit이라고 할려고 했냐? 라고 물어봐 주는 게 기본설정이다. 명령을 실행할 때 오타를 내면 자동으로 인식해서 실행하게 할 수 있다. 다음과 같이 설정하면 된다:

$ git config --global help.autocorrect 1

이 옵션이 설정되면 git comit이라고 실행하면 그냥 git commit이 실행된다:

CONFIG: GIT RERERE(REUSE RECORDED RESOLUTION)

Git: rerere에서 확인한다.

CONFIG: COLOR!

다음과 같이 설정하면 결과가 칼라로 나온다.

$ git config --global color.ui 1

ALIAS: GIT-AMEND

아래와 같이 alias를 등록하면 git amend라고 실행해서 HEAD 커밋을 수정할 수 있다. -C 옵션이 있기 때문에 커밋 메시지는 수정하지 않는다. 항상 커밋 메시지를 확인하고 싶으면 -C HEAD를 빼면 된다.

$ git config --global alias.amend "commit --amend -C HEAD"

ALIAS: GIT-UNDO

가장 최근 커밋을 되돌린다. --soft이기 때문에 그 커밋의 개체는 Staged 상태로 남는다:

$ git config --global alias.undo "reset --soft HEAD^"

ALIAS: GIT-COUNT

누가 얼마나 커밋했는지 보여준다:

$ git config --global alias.count "shortlog -sn"

SCRIPT: GIT-CREDIT

가장 마지막 커밋 author 정보를 바꿀일은 종종 생긴다. 실수일 수도 있고 아닐 수도 있지만 뭐 어찌됐건 최근 커밋의 author를 마음대로 바꾸고 싶을 때가 있다. 다음과 같이 config에 등록한다:

#!/bin/sh

git commit --amend --author "$1 <$2>" -C HEAD

git credit "Zach Holman" zach@example.com이라고 실행하면 최근 커밋의 author 정보가 변경된다.

@holman님은 @holman님의 dotfile 프로젝트에 가면 @holman님이 사용하는 git-credit 스크립트가 있다.

Octocat

이 슬라이드로 옥토캣은 다리가 4개고 꼬리가 1개라는 비밀을 알게 됐다. 맨날 보는 그림이지만 문어니까 그냥 다리가 8개라고 생각했었다.

잘 빠진 군체 알고리즘 - flock

2012-12-02T15:00:00.000Z

harry 님의 사이트에서 보았던 플로킹 알고리즘(flockng algorithm)을 정리했다.(무려 2011년 2월 글이다.) 플로킹 알고리즘은 떼(flock)의 각 개체의 행동 모델이다. 각 개체는 보이드(boid)라고 부르며 이들은 세 가지 규칙을 이용해 움직인다. 이 알고리즘은 1986년에 Craig Reynolds가 낸 논문에서 처음 소개되었다. 원래 알고리즘은 여기서 볼 수 있다. 그는 이 모델을 이용해 새 떼나 물고기 떼 등을 시뮬레이션했으며 배트맨 리턴즈의 박쥐 떼가 날아다니는 영상, 소셜 네트워크에서 의견의 흐름을 시뮬레이션해서 미래 의견을 예측하거나 분산 시스템에서도 이용되었다고 한다. 어디에서 쓰였는지는 링크를 확인하고 알고리즘이 어떻게 동작하는지 보자.

예제 먼저

옆의 버튼을 눌러서 한 보이드에 대한 자세한 정보와 그 범례를 볼 수 있다. :

구현은 harry 사이트의 것을 그대로 가져왔다. Coffee Script로 이루어져 있으며 HTML5의 canvas를 이용해서 애니메이션 데모를 보여준다. 따라서 애니메이션 데모를 보고 싶다면 canvas가 지원되는 브라우저로 들어오기를 바란다. 애니메이션은 ProcessingJS를 이용해서 이루어진다. (ProcessingJS에 대한 지식은 그리 필요하진 않다.) 이 페이지의 모든 애니메이션 데모는 버튼으로 애니메이션 속도를 조정할 수 있고 애니메이션 화면을 클릭해서 일시 정지시킬 수 있다. 물론 다시 클릭하면 다시 애니메이션이 진행된다. 정지 되었을 때에는 각 보이드에 마우스를 올려서 그 보이드의 정보를 볼 수 있다. 정보를 보는 법은 이 글을 읽으면서 알 수 있으니 성급해하지 말자.

보이드 - Boid

보이드는 무리를 이루는 개체 하나하나를 부르는 이름이다. 여기저기에서 에이전트라고 하기도 하고 오브젝트라고도 하지만 원문에 보이드라고 되어있으니 여기서도 보이드라고 부르기로 하자. 보이드는 위치와 속도를 데이터로 가지고 있다. 그리고 위에서 말한 세 가지 행동 규칙을 이용해 가속도를 계산한다. 가속도는 현재 속도에 영향을 미치고 속도에 의해 다음 위치가 결정된다. 이런 일을 하는 메서드가 step이다. 보이드가 너무 빨라지지 않도록 최고 속도를 정해놓고 그보다는 높아지지 않도록 조종하는 것도 중요하다. 다음 코드를 보자.

# Ported almost directly from http://processingjs.org/learning/topic/flocking
# thanks a whole lot to Craig Reynolds and Daniel Shiffman

class Boid
  location: false
  velocity: false

  constructor: (loc, processing) -&gt;
    @velocity = new Vector(Math.random()*2-1,Math.random()*2-1)
    @location = loc.copy()
    @p = processing

  # Called every frame. Calculates the acceleration using the flock method, 
  # and moves the boid based on it.
  step: (neighbours) -&gt;
    acceleration = this.flock(neighbours)
    @velocity.add(acceleration).limit(MAX_SPEED) # Limit the maximum speed at which a boid can go
    @location.add(@velocity)
    this._wrapIfNeeded()

  # Implements the flocking algorthim by collecting the three components 
  # and returning a weighted sum.
  flock: (neighbours) -&gt;
    separation = this.separate(neighbours).multiply(SEPARATION_WEIGHT)
    alignment = this.align(neighbours).multiply(ALIGNMENT_WEIGHT)
    cohesion = this.cohere(neighbours).multiply(COHESION_WEIGHT)
    return separation.add(alignment).add(cohesion)

제일 마지막 메서드인 flock이 앞으로 설명할 세 가지 행동 규칙으로 가속도를 만들어내는 메서드이다. 이에 대한 자세한 이야기는 이 글의 끝에서 하도록 한다.

응집 - Cohesion

보이드는 자기 주변의 보이드의 곁으로 가려는 성질이 있다. 즉 무리지으려는 성질이라고 볼 수 있다. ‘자기 주변의 보이드'는 자신 주변 반경 n 픽셀 안에 있는 보이드로 정의되고 NEIGHBOUR_RADIUS라는 상수가 그 주변을 결정하는 반경 값이다. 하나의 보이드는 주변 보이드들 사이의 무게 중심 쪽으로 방향을 튼다.

옆의 예제를 보면 분홍색 보이드의 Cohesion 정보가 표시되고 있다. 녹색 원이 자신의 주변을 뜻하는 범위이고 그 안에 들어온 보이드들은 녹색으로 표시된다. 그리고 짙은 보라색 화살표가 주변 보이드들의 평균 위치 한 점으로 모인다. 분홍색 보이드는 분홍색 화살표를 이용해 ‘나 그쪽으로 회전 중입니다'라고 알리고 있다.

코드

Cohesion은 NEIGHBOUR_RADIUS안에 있는 모든 보이드의 위치의 평균이다. 코드는 steer_to메서드를 거쳐 리턴한다. stear_to는 현재 위치와 갈 곳을 계산해서 보이드의 방향을 자연스럽게 틀어주는 역할을 한다. 일종의 보정이라고 생각하면 된다.

class Boid

  # 가속도를 계산할 때 cohesion요소를 계산하기 위해 호출한다.
  cohere: (neighbours) -&gt;
    sum = new Vector
    count = 0
    for boid in neighbours
      d = @location.distance(boid.location)
      if d &gt; 0 and d &lt; NEIGHBOUR_RADIUS
        sum.add(boid.location)
        count++

    if count &gt; 0
      return this.steer_to sum.divide(count)
    else
      return sum # 아무런 영향도 주지 않기 위해 빈 벡터를 리턴한다.

  steer_to: (target) -&gt;
    desired = Vector.subtract(target, @location) # 현재 위치에서 가려 하는 곳을 가리키는 벡터
    d = desired.magnitude()  # 현재 위치에서 목적지까지의 거리는 벡터의 크기이다.

    # 만약 거리가 0보다 크면 변경할 방향을 계산한다. (아니면 0을 리턴한다.)
    if d &gt; 0
      desired.normalize()

      # 원하는 벡터의 크기를 계산하기 위한 두 옵션(1 -- 거리에 기초하여, 2 -- 최대 스피드)
      if d &lt; 100.0
        desired.multiply(MAX_SPEED*(d/100.0)) # 이 제동은 임의적으로 정했다.
      else
        desired.multiply(MAX_SPEED)

      # Steering = Desired minus Velocity
      steer = desired.subtract(@velocity)
      steer.limit(MAX_FORCE)  # 방향 전환 정도에 제한을 둔다.
    else
      steer = new Vector(0,0)

    return steer

정렬 - Alignment

각 보이드는 주변의 보이드와 같은 방향을 향하려는 특성도 가지고 있다. 응집도와 비슷하게 NEIGHBOUR_RADIUS의 내에 들어온 주변 보이드들의 속도의 평균을 향한다. 속도는 방향과 크기를 가지고 있으므로 평균을 구하면 방향뿐만이 아니라 크기까지 평균이 된다. 따라서 주변 보이드의 속력이 빠를 수록 정렬되려는 힘도 커진다.

옆의 예제에서 보면 역시 분홍색 보이드의 정보가 보인다. 녹색 원 안에 녹색 보이드가 주변 보이드로 선정된 녀석들이고 주변 보이드의 속도는 녹색 화살표로 표시된다. 이 녹색 화살표의 평균이 분홍색 보이드의 연녹색 화살표이다. 검은색 화살표는 분홍색 보이드의 현재 속도이다. 분홍색 보이드는 다음 프레임에서 자신의 위치와 방향을 결정할 때 연녹색 화살표의 값을 이용한다.

코드

이번 코드는 그리 길지 않다. 로직은 응집도 계산과 똑같다. 다만 위치의 평균이 아니라 속도의 평균인 점이 다르다. 물론 이번에도 최대값이 있어서 너무 커다란 값이 되지 않도록 조정한다.

class Boid

  # Alignment component for the frame's acceleration
  align: (neighbours) -&gt;
    mean = new Vector
    count = 0
    for boid in neighbours
      d = @location.distance(boid.location)
      if d &gt; 0 and d &lt; NEIGHBOUR_RADIUS
        mean.add(boid.velocity)
        count++

    mean.divide(count) if count &gt; 0
    mean.limit(MAX_FORCE)
    return mean

분리 - Separation

각 보이드들은 너무 가까워지지 않으려는 경향이 있다. 보이드는 일정 공간을 두어 그 안으로 다른 보이드가 들어오면 그 보이드의 반대편으로 힘이 작용하여 멀어진다. 그 개인적인 공간은 DESIRED_SEPARATION이 결정하고 이 값은 NEIGHBOUR_RADIUS보다 작아야 한다. 만약 이 값이 NEIGHBOUR_RADIUS보다 크다면 이웃은 사라지고 모든 보이드를 배척하게 된다.

이번 예제는 빨간 원이 하나 더 생겼다. 이것이 DESIRED_SEPARATION값으로 결정된 생긴 개인 공간이고 이 안에 들어온 보이드는 빨간색으로 표시된다. 그리고 빨간 원 안으로 들어온 보이드에 의해 빨간 화살표로 멀어지려는 힘이 계산된다. 그 방향을 빨간 보이드의 반대 방향이 된다.

코드

코드를 보면 주변 보이드들과의 거리를 검사해서 DESIRED_SEPARATION보다 가까운 보이드와 거리를 정규화해서 평균을 낸다. 그 중간에 정규화된 벡터를 자신과 주변 보이드간의 거리에 반비례하게 크기를 변경한다. 이는 가까이 있을수록 더 빨리 멀어지고 싶어한다는 개념을 넣은 것이다.

class Boid

  # Separation component for the frame's acceleration
  separate: (neighbours) -&gt;
    mean = new Vector
    count = 0
    for boid in neighbours
      d = @location.distance(boid.location)
      if d &gt; 0 and d &lt; DESIRED_SEPARATION
        # Normalized, weighted by distance vector pointing away from the neighbour
        mean.add Vector.subtract(@location,boid.location).normalize().divide(d)
        count++

    mean.divide(count) if count &gt; 0
    mean

죄다 합쳐보자

위에서 계산했던 세 가지 행동 요소들을 이용해서 무리를 움직이게 하려면 아래와 같이 하면 된다. 보이드 클래스에 자신을 그리는 render메서드를 넣고 이 보이드의 무리를 만들어서 움직일 flock이라는 함수를 만들어 ProcessingJS의 인스턴스에 넘겨준다. flock에서는 보이드를 만들어 각 보이드의 step메서드와 render메서드를 넣어준다.

class Boid
  r: 2 # "radius" of the triangle
  render: () -&gt;
    # Draw a triangle rotated in the direction of velocity
    theta = @velocity.heading() + @p.radians(90)
    @p.fill(70)
    @p.stroke(255,255,0)
    @p.pushMatrix()
    @p.translate(@location.x,@location.y)
    @p.rotate(theta)
    @p.beginShape(@p.TRIANGLES)
    @p.vertex(0, -1 * @r *2)
    @p.vertex(-1 * @r, @r * 2)
    @p.vertex(@r, @r * 2)
    @p.endShape()
    @p.popMatrix()

# flock function, passed the Processing instance by Processing itself
flock = (processing) -&gt;
  start = new Vector(processing.width/2,processing.height/2)

  # Instantiate 100 boids who start in the middle of the map, have a maxmimum 
  # speed of 2, maximum force of 0.05, and give them a reference to the 
  # processing instance so they can render themselves.
  boids = for i in [0..100]
    new Boid(start, 2, 0.05, processing)

  processing.draw = -&gt;
    processing.background(255)
    for boid in boids
      boid.step(boids)
      boid.render()
    true

canvas = $('&lt;canvas width="550" height="550"&gt;&lt;/canvas&gt;').appendTo($('#flockingDemo'))[0]
processingInstance = new Processing(canvas, flock)

여기서 보이는 flock함수는 보이드의 flock 메서드와는 다르다. 위에 코드가 있지만 난 친절하니까 밑에 다시 코드를 적어주겠다.

flock: (neighbours) -&gt;
  separation = this.separate(neighbours).multiply(SEPARATION_WEIGHT)
  alignment = this.align(neighbours).multiply(ALIGNMENT_WEIGHT)
  cohesion = this.cohere(neighbours).multiply(COHESION_WEIGHT)
  return separation.add(alignment).add(cohesion)

자 이것이 보이드의 flock메서드이다. 보이드의 것은 세 가지 행동 요소(분리, 정렬, 응집)를 이용해 가속도로 사용할 값을 계산하는 것이다. 각 요소 값을 계산하고 그것을 그대로 쓰는 것이 아니라 그 것이 가속도에 끼칠 영향도(weight)를 곱해준다. 그 값은 각각 SEPARATION_WEIGHT, ALIGNMENT_WEIGHT, COHESION_WEIGHT이다. 보이드의 flock메서드는 각 요소에 영향도를 곱해서 전부 더한다. 그게 끝이다.
전체 코드는 여기에서 구할 수 있다.

변칙

다른 이웃

여기까지가 기본적인 플로킹 알고리즘이었다. 지금까지는 주변 보이드를 계산할 때 그냥 주변을 360도를 전부 검사했다. 하지만 만약 보이드가 인간이나 동물의 추상체라면 자신의 주변은 관찰 가능한 곳에 있는, 또는 눈에 보이는 보이드로 한정될 것이다. 따라서 주변 보이드를 계산할 때 자신의 뒤쪽은 배제할 수도 있다. 또는 정말 시야에 들어오는 보이드만을 이웃으로 규정할 수도 있다. 이런 이웃을 계산하는 방법에 따라 많은 변칙이 가능해진다.
공간에서 이웃은 위치상의 근접 개체이지만 다른 문제로 환원하면 논리적 근접을 다시 정의해야 한다. 예를 들어 만약 소셜 네트워크라면 이웃은 자신의 친구나 친구가 공유한 다른 친구로 될 것이다. 웹 사이트라면 직접 링크한 문서들을 이웃으로 정할 수도 있겠다.

영향도 수정

글에는 세 행동 요소들에 적용되는 영향도 값을 적어놓진 않았지만, 이 영향도 값들을 수정함으로써 보이드들이 다른 행동 양식을 보이도록 할 수도 있다.

장애물 피하기

위 데모가 진행되는 동안 마우스를 보이드로 가져다 대면 그들이 마우스 포인터를 휙휙 피하는 모습을 관찰할 수 있다. 아예 갈 수 없는 곳을 피하기도 하는데 이에 대한 설명은 글에서 하지 않았다. 공부를 더 해야 하지만 단순히 추측해보자면 특정 반경 안에 장애물이 감지되거나 장에물과 보이드가 충돌하면 속도를 줄이거나 멈추고 장애물이 없는 방향으로 속도를 올리는 것으로 생각된다. 장애물이 단순 벽일 때, 각이 있는 모서리 일 때, ㄷ자 형태의 벽일 때에 따라 장애물을 피해서 다시 빠져나갈 방법을 잘 설계해야 한다. 잘못하면 아마 벽에 무한으로 부히는 상황이 올지도 모른다.

마무리

이 글은 그냥 개인적으로 관심 있던 분야의 글이 뉴스 사이트에 올라왔고 호기심에 읽어본 글이 어쩌다 보니 이해되어 쓴 글이다. 이 모델을 어디에 사용할지는 아직 나도 모르겠지만 군체의 움직임이 예쁘게 모델링 되어있어 소개한다. 사실 예쁘게 모델링 되었다는게 정확한 모델링이라는 것과는 다른 말이지만 더 정교한 알고리즘의 기반 지식이라도 될까 기대해본다.

Git: rerere

2012-11-22T00:00:00.000Z

왠지 ‘거꾸로 해도 이효리'가 떠오르는 이 이름, 명령어는 외우기는 쉽지만, 용법을 이해하는 데는 공을 좀 들여야 한다.

어떤 Topic 브랜치는 오랫동안 Merge하지 않고 유지하기도 한다. 이런 Topic 브랜치를 Merge하면 Conflict가 날 확률이 높다. Conflict가 예상되는 브랜치를 Merge할 때 git rerere 명령으로 난관을 극복하는 방법을 알아보자.

이 글은 Rerere your boat…을 주로 참고 했다. 내용은 거의 같다.

rerere(Reuse Recorded Resolution)

rerere는 간단히 말하자면 Conflict를 해결한 Resolution을 저장해두고 같은 Conflict가 나면 저장한 Resolution을 재사용하는 명령이다.

Conflict가 발생하면 우선 conflict를 해결한 다음에, 다시 Merge하기 전으로 돌아와서 다시 Merge하면 저장된 Resolution이 적용돼서 Conflict 없이 자동으로 Merge된다.

어떻게 보면 말장난 같아 보일 수도 있다. Conflict를 Resolve하는 실험을 하고 실험에 성공하면 수동으로 그 실험을 재현해서 적용한다. 실패하면 다시 처음으로 돌아와 다시 시도한다. 그런데 이때 성공한 실험 내용을 기록해 뒀다가 자동으로 다시 적용하면 매우 편리할 것이다. rerere 옵션을 켜면 Conflict를 Resolve하는데 성공하면 그 내용을 자동으로 저장해주고 같은 일을 다시 시도하면 git이 자동으로 재현해준다.

그러면 이 명령어 어떻게 동작하는지 예제와 함께 살펴보자.

설정

rerere 기능은 설정해야 사용할 수 있다:

% git config --global rerere.enabled 1

각 저장소에 .git/rr-cache 디렉토리를 만들어도 이 기능이 켜지지만, 그냥 --global에 설정하자.

Hello World

hello.js 프로그램 하나인 프로젝트가 있다. master 브랜치의 hello.js 프로그램은 아래와 같다:

#!/usr/bin/env node

console.log( 'hello world')

그리고 아래와 같이 프로젝트를 진행한다. master 브랜치의 메시지를 'hola world'로 변경하고 i18n-world 브랜치의 메시지는 'hello mundo'로 변경한다:

이 상태에서 Merge를 하면 Conflict가 난다. 이 예제의 Conflict는 너무 간단해서 Recorded Resolution이 필요하지 않지만 rerere를 설명하기에는 더없이 좋은 예다.

Recored Resolution 만들기

@chacon님은 쓴 원래 글에서는 Conflict를 해결하는 브랜치에 바로 Merge하는 방법으로 Resolution을 만들었다. 그리고 Reset한 후에 다시 Merge해서 Resolution을 저장했다. 이 글에서는 detached HEAD를 이용하는 방법을 설명한다. 뭐 결과는 같지만 난 이 방법이 더 좋다.

먼저 detached HEAD 상태로 만든다:

% git checkout HEAD^0
Note: checking out 'HEAD^0'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

HEAD is now at 7d71bbe... hola world

master 브랜치가 가리키는 7d71bbe를 checkout 했기 때문에 워킹 디렉토리 내용은 master 브랜치와 같다. 단지 'detached HEAD’ 상태인 것만 다르다. 그래서 여기서 커밋을 하면 ‘detached HEAD’ 상태로 커밋된다. master 브랜치는 움직이지 않는다.

그러면 여기서 Merge한다:

% git merge i18n-world
Auto-merging hello.js
CONFLICT (content): Merge conflict in hello.js
Recorded preimage for 'hello.js'
Automatic merge failed; fix conflicts and then commit the result.

보통 Conflict 날 때의 상황과 다르게 “Recorded preimage for ‘hello.js’” 라는 메시지를 추가로 보여준다. rerere를 켰기 때문에 생겼다.

git status는 Conflict가 있다고 아래와 같이 알려준다:

% git status
# Not currently on any branch.
# Unmerged paths:
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
#       both modified:      hello.js
#
no changes added to commit (use "git add" and/or "git commit -a")

git diff라고 실행하면 어느 부분에서 Conflict가 난 것인지 보여준다:

diff --cc hello.js
index 68d2f27,2c3b5e5..0000000
--- a/hello.js
+++ b/hello.js
@@@ -1,4 -1,4 +1,8 @@@
  #!/usr/bin/env node

++<<<<<<< ours
 +console.log( 'hola world')
++=======
+ console.log( 'hello mundo')
++>>>>>>> theirs

이제 ‘hello.js’ 파일을 편집해서 ‘hola mundo'로 Conflict를 해결하고 저장한다. 아직 Resolve를 Mark하지 않은 상태에서 git diff를 실행하면 아래와 같이 나온다:

diff --cc hello.js
index 68d2f27,2c3b5e5..0000000
--- a/hello.js
+++ b/hello.js
@@@ -1,4 -1,4 +1,4 @@@
  #!/usr/bin/env node

- console.log( 'hola world')
 -console.log( 'hello mundo')
++console.log( 'hola mundo')

이 명령은 'hola world'가 'hello mundo'와 Merge돼서 'hola mundo'가 되는 거라고 보여준다. 그런데 웬걸 git add 명령으로 Resolution을 Mark하면 git diff 명령은 더는 이런 메시지를 보여주지 않는다. 대신 git rerere diff를 사용해야 한다:

--- a/hello.js
+++ b/hello.js
@@ -1,8 +1,4 @@
 #!/usr/bin/env node

-<<<<<<<
-console.log( 'hello mundo')
-=======
-console.log( 'hola world')
->>>>>>>
+console.log( 'hola mundo')

Resolution은 다 만들었고 이제 커밋한다:

% git commit -m 'sample resolution'
Recorded resolution for 'hello.js'.
[detached HEAD f35bf55] sample resolution

“Recorded resolution for 'hello.js’"라는 메시지는 Resolution이 저장됐음을 보여주는 것이고 "detached HEAD"는 detached HEAD 상태에서 커밋했기 때문에 보여주는 것이다.

이제 Resolution은 다 만들었다. Conflict를 해결하는 실험을 성공적으로 마친 것이다. 이 실험 결과를 실전에 적용해보자.

rerere

i18n-world를 master로 Merge하기 전에 i18n-world를 Rebase한다. 먼저 i18n-world를 Checkout한다:

% git co i18n-world
Warning: you are leaving 1 commit behind, not connected to
any of your branches:

  f35bf55 sample resolution

If you want to keep them by creating a new branch, this may be a good time
to do so with:

 git branch new_branch_name f35bf550d886286e5e75569fb9597c664cd7743d

Switched to branch 'i18n-world'

detached HEAD에서 벗어난다는 경고 메시지를 보여준다. 그리고 Rebase한다:

% git rebase master
First, rewinding head to replay your work on top of it...
Applying: hello mundo
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging hello.js
CONFLICT (content): Merge conflict in hello.js
Resolved 'hello.js' using previous resolution.
Failed to merge in the changes.
Patch failed at 0001 hello mundo

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To check out the original branch and stop rebasing run "git rebase --abort".

"Resolved ‘hello.js’ using previous resolution” 메시지가 추가돼 있다. 편집기로 hello.js를 열어보면 좀 전에 만들었던 Resolution대로 파일이 Resolve됐음을 알 수 있다. git diff 명령으로 차이를 확인할 수 있다:

% git diff
diff --cc hello.js
index 68d2f27,2c3b5e5..0000000
--- a/hello.js
+++ b/hello.js
@@@ -1,4 -1,4 +1,4 @@@
  #!/usr/bin/env node

- console.log( 'hola world')
 -console.log( 'hello mundo')
++console.log( 'hola mundo')

그러면 이 상태에서 Resolution을 Mark하고 git rebase --continue를 실행하면 Rebase가 완료된다. 아래와 같이 실행한다:

# git add .
# git rebase --continue
Applying: hello mundo

rerere를 이용한 Merge를 마쳤다. ‘detached HEAD’ 상태를 만들어서 Conflict를 해결하는 실험을 하고 Resolution을 만들어 놓는다. 그다음에 다시 Merge를 하면 만들어 놓은 Resolution이 재사용된다. 그래서 명령어 이름이 ‘rerere(REuse REcorded REsolution)'이다.

Resolution을 재사용하지 않기

Resolution을 Mark하기 전으로 돌아가 보자. git rebase master를 실행하면 자동으로 저장된 Resolution이 적용된다. 그 상태로 돌아가서 git diff를 실행하면 결과는 아래와 같다:

% git diff
diff --cc hello.js
index 68d2f27,2c3b5e5..0000000
--- a/hello.js
+++ b/hello.js
@@@ -1,4 -1,4 +1,4 @@@
  #!/usr/bin/env node

- console.log( 'hola world')
 -console.log( 'hello mundo')
++console.log( 'hola mundo')

여기서 git이 자동으로 적용해준 Resolution이 마음에 들지 않으면 다시 Conflict 파일을 생성할 수 있다:

% git checkout --conflict=merge hello.j
% cat hello.js
#!/usr/bin/env node

<<<<<<< ours
console.log( 'hola world')
=======
console.log( 'hello mundo')
>>>>>>> theirs

--conflict 옵션은 Conflict를 해결할 때 사용하면 유용하다. merge 대신 diff3를 사용하면 base Commit의 것도 알 수 있다. Checkout명령은 .git 데이터베이스에 들어 있는 내용을 워킹 디렉토리로 복사하는 명령이다. 이 명령을 실행하면 충돌이 표시된 hello.js파일이 워킹 디렉토리에 생성된다:

% git checkout --conflict=diff3 hello.js
% cat hello.js
#!/usr/bin/env node

<<<<<<< ours
console.log( 'hola world')
||||||| base
console.log( 'hello world')
=======
console.log( 'hello mundo')
>>>>>>> theirs

이제 원하는 데로 편집하고 git add .;git rebase --continue 명령을 실행하면 Rebase는 완료된다. 하지만, 저장해둔 Resolution을 다시 적용하고 싶어지면 아래와 같이 복원한다:

% git rerere
Resolved 'hello.js' using previous resolution.
% cat hello.js
#!/usr/bin/env node

console.log( 'hola mundo')

Conflict를 다시 해결했으니 계속 진행해서 Rebate를 완료한다:

# git add .
# git rebase --continue
Applying: hello mundo

이상으로 rerere 명령에 대해 알아보았다.