AI Convergence

Git의 열거형 명령을 하나의 Alias로 지정할 수 있다. 설정 방법을 알아보자 

1) Alias 설정하기 : git config --global alias.[Alias명] '[명령]'

  - Ustage상태로 변경 : git config --global alias.unstage 'reset HEAD --' 로 설정하면 하기 명령은 동일하다 

    $ git unstage fileA

    $ git reset HEAD fileA 

  - last 명령 : git config --global alias.last 'log -l HEAD'

2) 많이 사용하는 git alias : 참조사이트 

* 현 브랜치의 히스토리를 short SHA값, author 정보, 커밋 트리 그리고 히스토리에서 특정 커밋을 가르키는 refs(브랜치, 태그)보기

  $ git config --global alias.lg "log --name-status --color --abbrev-commit --date=relative --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset'"

  $ git lg 결과를 색깔별로 보여줌 

* 브랜치를 중심으로 히스토리를 보고 싶을 경우

  $ git config --global alias.tree "log --graph --decorate --pretty=oneline --abbrev-commit --all"

  또는 $ git config --global alias.lol 'log --oneline --graph --decorate'

  $ git tree 또는 git lol 수행 결과

* Visual 윈도우에서 변경 내역 보기 

  $ git config --global alias.visual '!gitk'

  $ git visual 을 수행하면 하기 화면이 뜬다 

<참조>

  - dogfeet alias 설정

  - 개발자 하루 alais 설정

  - 자료 : 민트기술

   Git-Guide-r1.pdf

SVN의 Tag처럼 Git에도 Tag가 있다. 어떻게 사용하는지 보자 

1) Tag 조회하기 : git tag 

  - 특정 버전 조회시 git tag -l 'v1.4.2.*' 식으로 조회한다

2) Annotated Tag 붙이기 : git tag -a [버전] -m '[메시지]'

  - Tag를 만든 사람의 이름, 이메일, 날짜, 메시지를 저장함. 단순 Tag일때는 Lightweight Tag를 사용함 

  - Tag 정보와 커밋 정보 보기 : git show [버전]

3) Lightweight Tag : git tag [버전]

  - 브랜치처럼 가리키는 지점을 최신 커밋으로 이동시키지 않는다. 단순 특정 커밋에 대한 포인터일 뿐임 (체크섬만을 저장할 뿐)

  - -a, -s, -m 등의 옵션을 사용하지 않는다 

4) Tag 검증하기 : git tag -v [버전]

  - GPG 서명을 검증하는 것으로 공개키가 필요하다

  - 서명 메시지가 없으면 하기와 같은 error 메시지가 나옴 (다음 기회에 다시 알아보자)

5) 나중에 Tag 하기 : git tag -a v1.2 [해쉬값 앞 7자리] -m '[메시지]'

  - 과거 특정 커밋에 대해서 Tag를 달 수 있다. 커밋 내역 확인하기 : git log --pretty=oneline

6) Tag 공유하기 : git push origin [버전]

  - 서버로 Branch를 push 하는 것과 동일하다 

  - 한번에 여러 개의 tag를 push 하기 : git push origin --tags

GitHub에 만들어 놓은 저장소 관리를 알아보자. 

1) 리모트 저장소 확인하기 

2) 리모트 저장소 추가하기 : git remote add [단축이름] [url] 

3) 리모트 저장소를 Pull, Fetch 하기 : git fetch [remote-name] 

   - fetch : clone 이후 변경된 데이터를 모두 로컬로 가져온다. 그러나 자동 Merge는 하지 않는다. 수동 Merge해야 함

   - pull : 리모트 저장소 브랜치에서 데이터를 가져와서 현재 작업하는 로컬 브랜치와 Merge 한다. 

4) 리모트 저장소에 Push 하기 : git push [리모트 저장소 이름] [브랜치 이름]

5) 리모트 저장소 살펴보기 : git remote show [리모트 저장소 이름]

Git 저장소를 만들고 Working Directory, Staging Area, Git Directory를 오가는 명령을 알아보자.

> Git 저장소 만들기 

• 프로젝트 디렉토리를 만든다
• 프로젝트 디렉토리로 이동한다
• git init 명령을 수행하면 .git 디렉토리가 생긴다 (git 뼈대)
• 버전관리를 시작할려면 git add -> git commit 을 하여 파일을 저장소에 추가해야 시작된다.

> Git 복제 

• git clone <url>

> 파일 수정하고 저장소에 저장하기 

• Tracked(관리대상)와 Untracked(비관리대상) 으로 나뉜다. 즉 한번이라도 commit 되면 관리대상이 된다.
• Tracked는 Unmodified(수정하지 않음)와 Modified(수정함) 그리고 Staged(커밋전) 상태 중 하나이다.
• Clone을 하게 되면 모든 파일은 Tracked이면서 Unmodified 상태이다. 또한 자동으로 자동 Checkout도 한다.

untracked <-> unmodified <-> modified <-> staged <-> commited

• git status : 파일 상태의 확인 tracked와 modified 상태파일이 없거나, Untracked 파일이 있는지 보여준다

• git add <파일명 또는 디렉토리경로명> : Tracked 상태로 만들면서 Staged 상태가 된다 

• Modified 상태의 파일을 Stage 하기 

• Stage 된 파일을 다시 Modified 하였을 경우 

• .gitignore : Untracked 파일을 git 목록에서 제거하기 (로그파일, 빌드환경파일, 프로젝트파일등 무시하고자 하는 것을 명시한다)
• 아무것도 없는 줄이나 # 시작하는 줄 무시
• 표준 Glob 패턴 사용 (Glob패턴은 정규표현식을 단순하게 만든 것으로 보통 쉘에서 사용)
• * : 문자가 하나도 없거나 하나 이상을 의미 
• [abc] : 중괄호 안에 있는 문자중 하나를 의미
• ? : 문자 하나를 의미
• [0-9] : 하이픈을 사용하면 그 캐릭터 사이의 문자 하나를 의미
• 디렉토리는 슬래쉬(/)를 끝에 사용
• 느낌표(!)로 시작하는 패턴은 해당 패턴의 파일 무시

• git diff : Staged와 Unstaged 상태의 변경 내용을 보기 (git status 는 단순 상태 정보만을 보여주지만 git diff는 변경 내용을 볼 수 있다)

• git commit <fileName option> -m <message> : Staging Area 파일을 정일한다. 즉, Staged 파일만 해당 된다. git add 하지 않은 파일은 Modified 상태로 남음.

• git commit -a -m <메세지> : Staging Area 생략하고 commit 하기. 

• git rm <파일> : 삭제된 파일은 Staging 상태가 된다. 다시 commit을 하면 삭제가 된다. (삭제확인을 위한 장치). 만일 Staging Area에서 포함되지 않게 제거하는 것은 git rm --cached를 사용한다.

• git mv <from파일> <to파일> : 파일 이름 변경하기를 하면 Staging Area에 Renamed 상태로 된다.

• git log : 커밋 히스토리 보기. 가장 최근 커밋이 가장 먼저 나온다. -p 옵션은 커밋의 diff 결과를 보여준다. -2 는 두개의 결과만 보여준다. -p 옵션은 diff이기 때문에 동료의 변경 내용을 빠르게 확인 할 수 있다. --stat 각 커밋의 통계 정보를 보여줌. --pretty는 사용자 정의가능 (oneline, short, full, fuller, format 옵션 예, --pretty=oneline). --graph는 브랜치 그래프를 보여줌

* git log 옵션들

Git 설치에 대해 간단히 알아보고, 설정하는 방법에 대하여 알아보자 

> Git 설치

• Git은 curl, zlib, openssl, expat, libiconv를 필요로 한다 

// 윈도우 설치
http://code.google.com/p/msysgit  다운로드하여 설치한다

• http://git-scm.com/download 에서 최신 snapshot을 받아서 컴파일하고 설치한다

$ cd git-1.7.2.2
$ make prefix=/usr/local all
$ sudo make prefix=/usr/local install

• Git이 이미 설치되었다면 최신버전 소스를 다음과 같이 받을 수 있다. 

> Git 환경파일

• /etc/gitconfig : 시스템의 모든 사용자와 모든 저장소에 적용되는 설정. git config --system 옵션으로 RW 가능.
• ~/.gitconfig : 특정 사용자에게만 적용(윈도우는 USER 밑에 존재) git config --global 옵션으로 RW 가능.
• .git/config : Git Directory(Local Repsoitory)의 현재 작업중인 프로젝트에만 적용. 우선순위 가장 높음.

Pro Git에 대한 번역본을 보면서 공부한 내용을 정리한다. 

> 버전 관리 형태 

• VCS : 초창기 로컬 버전 컨트롤 시스템으로 시작
• CVCS : 중앙 버전 컨트롤 시스템 (단점 : 중앙 저장소 장애시 모든 개발자 접속 불가. 예: SVN, CVS)
• DVCS : 분산 버전 컨트롤 시스템 (장점 : CVCS 단점 극복, 중앙 저장소를 그대로 로컬에 복제하여 사용함. 예:  Git)

> Git 역사

• 리눅스 초창기 개발에서 쓰던 BitKeeper DVCS가 상용화 요구하면서 개발됨
• 빠른 속도, 단순한 구조, 동시 다발적 브랜치(비선형적 개발), 완벽한 분산, 대형 프로젝트에도 적함(속도, 크기면에서도) 요건 충족토록 개발시작
• 2005년 탄생

> Git 특성

• Git 데이터는 파일 시스템의 SnapShot 으로 크기가 작다. 파일 변경이 없으면 버져닝시 이전 파일의 링크만 저장한다.
• 거의 모든 명령은 로컬에서 수행된다. (CVCS는 네트워크 속도에 영향을 받는다) 오프라인 상태에서도 작업이 가능하다.
• 데이터 무결성을 위해 모든 데이터 저장전 체크섬(Checksum 또는 Hash)을 구하여 관리한다. SHA01 Hash를 사용하여 체크섬을 만든다. (길이 40자 16진수 문자열)
• 로컬에 3 단계로 나뉜다 : Working Directory (Modified) - Staging Area (Staged) - Git Directory(Local Repository, Commited)
• Working Directory : 특정 버전을 Checkout 한 것이다. Git Directory에 압축된 데이터베이스 파일을 가져와 만든다
• Staging Area : Git Directory에 있고, 단순 파일이고 곧 Commit 할 파일에 대한 정보이다. 종종 인덱스라고 불림.
• Git Directory : 프로젝트의 메타데이터와 객체 데이터베이스를 저장하는 곳이다. Git의 핵심이다. 

Git 내부 저장소를 최적화 해주는 작업과 zip/tar로 묶는 방법에 대해 알아보자 

• git gc : 저장소의 크기 압축 및 최적화 (지저분한 내용을 정리)
• git gc --aggressive : 변경 사항 델타(delta)단위로 저장한다. 저장단위를 처음부터 최적화 한다 

• git archive --format=zip --prefix=aa/ HEAD > bb.zip : zip 포멧으로 aa/ 디렉토리 밑으로 모든 파일을 넣어서 HEAD에서 압축 생성하여 bb.zip파일을 만든다 
• git archive --format=tar --prefix=aa/ HEAD | gzip > bb.tar.gz : 상동. 단, gz에 대하여 gzip 압축 추가 함 

* 참조 : Git 선화

git은 브랜치로 코드를 다룬다. 릴리즈 브랜치는 릴리즈할 코드를 분리할 목적에서 사용한다.

• 구현하기로 한 기능 구현이 끝나면 릴리즈할 코드를 분리할 목적으로 브랜치를 생성한다. (완전히 검토된 상태는 아님)
• 최소한의 변경은 발생하며, 버그나 로직 수정에만 집중한다 (기능추가 없음)
• 이름은 RB_ 로 접두어를 붙이면 좋다
• 릴리즈 브랜치는 마지막 테스트까지만 존재한다
• 릴리즈 준비가 끝나면 태그(Tag)를 붙이고 해당 브랜치를 삭제한다 
• 해당 릴리즈의 수정은 태그에서 브랜칭하여 수정 처리한다 

* 참조 : Git 선화

Git의 tag는 코드의 책깔피와 같아서 릴리즈된 코드에 tag를 달아두면 언제나 해당 태그로 이동할 수 있다. 즉, Freezing Code Release 정도로 보면 되겠다. Tag 는 브랜치처럼 다루어 지지만 읽기만 가능하다. 따라서 변경을 하고 태그로 부터 별도 브랜치를 생성하여 진행하면 된다. 

릴리즈 버전에 대하여 코드 freezing 시에 사용하자 

Git은 분산 버전 관리 시스템이므로 원격의 공유 저장소가 있다. Private 하게 원격 저장소를 구축할 수도 있고, 요즘은 GitHub을 SaaS 형태로 사용하면 된다. GitHub에선 Public과 Private이 있는데, Public 은 공짜, Private은 subscription 모델로 월단위로 과금을 한다. 

▶ remote 저장소 주소들 (GitHub기준)

• SSH (Secure Shell) : git@github.com:<아이디>/<프로젝트>.git   (주로 write 권한을 주고자 할 때 사용 - push)
  예) git@github.com:ysyun/jmqtt_client.git
• GIT 프로토콜 :  git://github.com/<아이디>/<프로젝트>.git  (주로 read 권한을 주고자 할 때 사용. 9418포트 사용 - pull)
  예) git://github.com/ysyun/jmqtt_client.git
• HTTP, HTTPS : https://github.com/<아이디>/<프로젝트>.git  (속도 제일 느리지만 방화벽 오픈 필요없음)
  예) https://github.com/ysyun/jmqtt_client.git

▶ remote 저장소에 대한 별칭 관리

• git remote add <별칭> <원격지 주소> : 예) git remote add origin https://github.com/ysyun/jmqtt_client.git
• origin : 원격 저장소를 가르키는 일반적인 별칭으로 사용한다. 
• git remote -v : 별칭한 내역을 볼 수 있다
• git branch -r : 별칭에 대한 remote repository의 branch를 볼 수 있다 
• git remote rm <별칭> : 별칭을 제거한다 

• github의 경우는 머전 github에서 프로젝트의 remote repository를 생성한다
  
• git clone <remote address>를 통하여 local PC의 local repository로 복제를 한다 (위 예제 참조)
• git fetch <remote> <refspec> : 지역 저장소의 원격 브랜치가 갱신됨 (지역 브랜치에 변경사항을 합치진 않음)
• git pull : default origin 원격 저장소에서 현재 브랜치로 merge 함 
• git pull <remote> <refspec> : 원격 장소에서 가져온 소스를 현재 지역 브랜치에 merge 함
• <remote> : 원격 저장소의 별칭 origin을 입력하면 된다. 별칭이 없다면 전체 주소를 넣어야 한다.

▶ remote 저장소 Pushing

• git push : default origin 저장소를 & 현재 브랜치를 원격의 같은 브랜치로 푸싱한다 
  
• git push <remote> <branch> :현재 브랜치를 원격의 신규 또는 존재하는 branch로 푸싱한다
• git push <remote> <branch1>:<branch2> : 지역 branch1을 원격의 신규 또는 존해하는 branch2로 푸싱한다 
• git push --dry-run <매개변수>: 푸싱된 변경 사항을 확인
• <remote> : 원격 저장소의 별칭 origin을 입력하면 된다. 별칭이 없다면 전체 주소를 넣어야 한다.

* 참조 : 선화의 Git

Git의 local repository의 commit 히스토리를 보고, 관리하는 방법에 대해서 알아보자. 참조 블로그 내용을 명령어 위주로 정리함.

▶ 리비전 로그와 범위 알아보기 

• git log : 지금까지 수행한 내역이 전부 보인다. 끝낼 땐 :q 차례로 입력한다
• git log <hash id 7자리> : 특정 커밋내역만 출력 (출력 형식 : 커밋명, 작성자, 날짜, 로그메세지)
• git log --since="5 hours" : 5시간 동안 현재까지 (minute 또는 2012-10.01 날짜 형식가능)
• git log --before="5 hours" : 현재부터 5시간을 제외하고 5시간 전의 모든 커밋내역 보기 
• git log 184dfa1..HEAD : 해쉬아이디부터 현재(HEAD)까지 로그 내역 (HEAD 생략가능)
• ^ : 캐럿문자 -1 취급 (12819fe^ = 12819fe와 일치하는 리비전 바로 이전 리비전으로 해석), 여러 캐럿 사용가능 예) 34fa3rt^^ 
• ~N : 커밋명에 N만큼 뺌 (12819fe~1 = 12819fe 바로 이전 리비전을 나타냄)
• git log -1 HEAD^~2 = git log -l HEAD~1^^  같은 의미의 리비전 필터링임

• git diff --stat 1.0 : 릴리스 사이의 통계를 보여줌
• git blame <fileName> : 누구의 책임인지 보여줌 
• git commit -C HEAD -a --amend : 커밋 수정하기 -> 커밋된 것을 다시 스테이징으로 옮겨줄 때 --amend를 사용한다 
• git revert -n HEAD : 기존 커밋을 다시 돌려 놓을때 사용 -> 이전 커밋상태로 돌아감 
• git reset --hard HEAD : 저장소 재설정임. 이전 커밋의 오류를 수정하려는 경우 사용 (--soft는 스테이징으로 옮김, --hard는 저장소와 작업트리에서 커밋을 완전 제거해 버림)
• git rebase : 커밋 순서를 대화형으로 재배치 하는 것이다 (vi식으로 커밋 순서를 재배치 하는 것이다)
• git rebase -i HEAD~3 : vi로 위치조정 -> 저장하면 rebase 작업을 수행한다
• git log --pretty=format="%h %s" HEAD^3 : 변경 내역 확인

git은 branch를 만들어 "테스트할 기능", "새로운 기능", "버그 픽스"등에 대하여 만들고, master에 다시 merge를 할 수 있다. branch를 만들고, merge하는 방법을 알아보자 

▶ Git 제어

• git branch new : 새로운 branch 를 만든다. 아무런 내역이 없다.
• git checkout new : 새로 만든 new 브랜치로 이동한다 
• git checkout -b alternate master : master를 복제하여 브랜치를 만들고 alternate로 checkout 이동한다 
• git branch -m alternate alternative : 브랜치의 명칭을 alternative로 변경한다 (-M 기존 같은 명칭 브랜치 있어도 덮어씀)
• git brranch -d alternative : alternative 브랜치를 삭제한다 (-D 옵션은 강제 삭제)

• Straight Merge (바로 합치기) : 브랜치 변경 이력 전체를 합치는 방법
  
• Squashed Commit (커밋 합치기) : 한 브랜치 이력 압축하여 다른 브랜치의 최신 커밋으로 하나 만드는 방법
• Cherry-picking (선택하여 합치기) : 다른 브랜치의 하나의 커밋을 현재 브랜치에 적용하는 방법

• git checkout -b alternate master
• git add about.html (내용 넣음) -> git commit -m "add about"
• git checkout master 
• git merge alternate : master 브랜치에 alternate 브랜치를 합친다 (즉, about.html 파일이 신규로 합쳐짐)

• git checkout -b contact master
• git add contact.html (주소 내역 추가) -> git commit -m "add contact address"
• contact.html (email 내역 추가) -> git commit -a -m "add contact email" (즉, commit object 두개가 된다)
• git checkout master
• git merge --squash contact : contact의 커밋 두개를 하나로 만들어 master의 staging에 추가함 (git status 확인)
• git commit -m "add contact address" -m "add contact email"  (master 브랜치에 contact.html 을 커밋한다)

• git checkout contact
• git commit -a -m "add contact sns id" (contact.html안에 twitter 계정추가 commit object Hash 코드를 34abcd 로 가정함)
• git checkout master
• git cherry-pick 34abcd  ( contact 브랜치의 34abcd 커밋을 master 브랜치에 커밋한다)
• git reset --hard HEAD 마지막 커밋을 master 브랜치에서 제거
• git cherry-pick -n 34abcd ( -n 옵션 사용하면 master 브랜치의 staging에 넣음, 커밋안함. git status 로 확인)
• git commit (최종 커밋함)

• git checkout -b about master : about 브랜치 생성 후 checkout
  
• git add about.html (about 내역 입력) -> git commit -m "add about"
• git branch about2 abut : about 브랜치를 기반하여 about2 브랜치를 생성
• git commit -a -m "add XXX" : about 브랜치의 about.html 파일에 XXX 입력
• git checkout about2 
• git commit -a -m "add YYY" : about2 브랜치의 about.html 파일에 YYY 입력 (이제 about 브랜치의 about.html과 about2 브랜치의 about.html 파일에 XXX 와 YYY 충돌이 발생함)
• git checkout about
• git merge about2 : about2 브랜치를 about 브랜치로 바로 합치기
• about.html 안에 conflict 내역이 표시됨 : 내역을 직접 수정하거나, git mergetool 명령으로 merge.tool 값 확인하고 도구로 합치기 시도함 (도구 사용법은 다시 상세히 봐야겠음)

Git의 로컬 Repository에 저장된 commit 내역에서 이전 commit 내역으로 이동하고 싶을 경우. HEAD를 조작함으로써 가능하다. 

• 지금 까지 커밋 내역 보기 : git reflog  (하기 내역으로 파란색으로 3 번의 commit 이 존재한다)

• c6d5478 commit 내역에서 aa64af1 commit 내역으로 이동하기 : git reset --soft HEAD~  (staging, working 영향없음)
• --mixed 는 staging을 local repository와 같게 만든다. 즉, staging에 HEAD정보를 복사하여 영향줌. working 영향없음 
• --hard 는 staging, working 둘다 영향을 줌

• aa64af1 commit 으로 이동했을 때 상태 정보를 확인 : git status  (c6d5478 commit 되기전 rename 명령을 내렸었음)

• Git 에서 HEAD, Branch는 Pointer이다 

commit을 하여 Blob format으로 되어 있는 binary 파일에 대한 명칭은 SHA-1 해쉬알고리즘으로 해쉬명을 가지고 있다. 파일명과 해쉬명을 오가면 확인하는 방법을 알아보자 

• 파일명 통하여 해쉬명 알아내기 : git hash-object <fileName>

• 해쉬명 앞 6자리를 통하여 변경 내역이 무엇인지 파악하기 : git cat-file -p <해쉬명 앞 6자리>

• 전체 해쉬에 대한 파일명 맵핑 목록 보기 : git ls-files -s  ( .git/index 파일 내역을 참조함 )

▶ Git의 4가지 객체

> Blob Object

• Header + Content 
• zlib으로 압축되어 있음
• .git/objects/ 아래 있음 

• blob + 다른 tree 객체
• 폴더와 같은 개념
• .git/objects/ 아래 있음 

• blobs + trees + author + date + message
• .git/objects/ 아래 있음

• pointer to commit object
• .git/refs/tags/ 아래 있음 

* 참고 : 개발자를 위한 고급 Git 활용 (p50부터)

git에서의 commit은 오직 로컬 레파지토리와 관계가 있다. SVN이 자신의 로컬 PC에 있다고 생각하면 된다. 개발자 혼자서 마음대로 가지고 놀 수 있는 레파지토리인 셈이다. 

어디에서 수행할 수 있을까? (참조)

• workspace
• commit -a -m 'msg'  : "workspace" -> "local repository"
• index
• commit -m 'msg' : "index" -> "local repository"
• commit --amend :  "index" -> "local repository" (마지막 commit 수정하고 새로운 commit을 한다 )

commit이란?  (참조)

• workspace 또는 index(stage)의 소스를 local repository로 저장하면서 "새로운 commit object"가 생성된다. 
• 이때 HEAD와 현재 Branch가 가르키는 포인터는 "새로운 commit object" 주소로 바뀐다
• index의 포인터도 "새로운 commit object" 주소로 바뀐다 

diff는 commits 된 것들 사이에서 차이를 보기위한 방법이다. (참조) 

어디에서 수행할 수 있는가?

• workspace 입장 (Working Directory)
• git diff : "workspace" <- "index"
• git diff HEAD or <another branch> : "workspace" <- "local repository"
• index 입장 (Stage)
• git diff : "workspace" <- "index"
• git diff --cached : "index" <- "local repository"
• local repository 입장
• git diff HEAD  or <another branch>  : "workspace" <- "local repository"
• git diff <commit 1> <commit 2> : "local repository" commit 1 -> commit 2
• git diff --cached : "index" <- "local repository" 

위 내용에 대한 정리를 보자. 

• 선화님 블로깅 : 예제를 기반한 상세 설명

GitHub의 Wiki는 단순 페이지만을 생성하는데, 일반 위키들 처럼 오른쪽에 목차가(Sidebar) 나오고 하단에는 footer등을 넣고 싶을 경우 다음을 참조하자 

• http://blackbe.lt/github-wiki-sidebar-table-contents-header-footer/
• Wiki의 Git Access로 들어가서 wiki git 주소를 pull해서 위키를 작성하고 다시 push를 해도 된다는데 살펴볼 일이다
• 참조 GitHub Project :  https://github.com/MLstate/opalang/wiki

• OSS인 골룸(gollum)을 통해서 GitHub의 wiki를 확장할 수 있다
• Sidebar 넣기 
• _Sidebar.ext 파일을 만든다. 물론 내용은 wiki 형식을 따르면 된다 : .md파일이 없는 모든 sub directory에 영향을 미친다 (요건 체크해 볼일이다)
• wiki git을 checkout 한다 (wiki의 Git Access 탭에서 git url을 얻으면 됨)
• wiki repository를 local로 다 가져온후 _Sidebar.md 파일을 만든다
• .md 파일안에 markdown syntax로 link를 [[link]] 형식으로 넣는다 
• _Sidebar.md 파일을 commint한후 origin master에 push 한다 
• Header 넣기
• _Header.ext 파일 만든다 (wiki 포멧)
• _Header.md 파일 만든다 (markdown syntax)
• Footer 넣기
• _Footer.ext 파일 만든다 (wiki 포멧)
• _Footer.md 파일 만든다 (markdown syntax)  

요점만 정리했는데, 실제로 해볼일~~에구구

SVN에 대하여 잘 설명해 놓은 글이 있네요. Branch와 HEAD, revision에 대한 내용등과 merge할때 상황별 정책도 정리해 놓았네요. 

강추 : http://ghostsheep.tistory.com/9