'분류 전체보기'에 해당되는 글 168건
- 2014.01.25 책 "DOM을 깨우치다" 정리노트 :: Node 개요
- 2014.01.01 Ext JS 4: The Class Definition Pipeline
- 2013.09.15 powerline 설치 방법(mac 기준)
- 2013.09.10 JS 객체 설계 시 This를 반환하는 이유.
- 2013.08.22 Git fork, pull request 테스트
- 2013.08.21 Git rebase 명령(커밋 수정(합치기)) 테스트
- 2013.08.18 Git remote fetch/pull, Git push 명령
- 2013.08.18 Git reset 명령 테스트
- 2013.08.14 기본적인 Git 명령어
- 2013.08.08 AJ 님의 "Advanced Git" 슬라이드 Study - 4
책 "DOM을 깨우치다" 정리노트 :: Node 개요
DOM 정의:
- Dom(Document Object Model)은 웹 서버를 통해 내려받은 "HTML" 코드를 브라우저가 해석 후 JavaScript 객체를 통해 계층화한 구조체(의미상(트리 구조))를 의미한다.
구조체란?: http://ko.wikipedia.org/wiki/Struct
DOM 목적:
- JavaScript를 통해 문서(HTML, XHTML, XML 등)의 각 요소들을 핸들링하기 위한, 프로그래밍 인터페이스를 제공한다.
DOM 트리:
- HTML 문서의 각 요소들은 가장 오른쪽 패널에서와 같이 브라우저에 의해 해석된 후, Javascript 객체(Object, Node 등)를 통해 계층화된 트리 구조로 변환된다.
또한, 브라우저를 통해 생성(해석 후)된 DOM에 대한 JavaScript 객체 상속 관계는 아래와 같다.
츨처: http://www.stanford.edu/class/cs98si/slides/the-document-object-model.html
DOM 상속 관계:
- 아래 그림의 상속 관계는 html 엘리먼트의 상속 관계를 나열한 것이며, 객체 상속의 시작은 최상위 조상인 Object.prototype 객체로 부터 참조가 시작된다.
1. EventTarget.prototype 객체는 Object 객체를 상속받아 확장한다.
2. Node 객체는 EventTarget 객체를 상속받아 확장한다.
3. DocumentType 객체는 Node 객체를 상속받아 확장한다.
정리하면, 아래와 같은 상속 관계가 만들어지며, DOM 상의 모든 ElementNode들은 아래 나열한 객체들을 상속받아 확장하게되는 것이다.
Object < EventTarget < Node < DocumentType < <!DOCTYPE html>(ElementNode)
또 다른 예로, html 요소를 클릭 시 아래 그림과 같은 상속 관계를 확인할 수 있다.
Object < EventTarget < Node < Element < HtmlElement < HtmlhtmlElement < html(ElementNode)
- 결국 아래 코드와 같이 html ElementNode는 상속(Object, EventTarget, Node, Element, HtmlElement, HTMLhtmlElement) 받은 모든 객체의 속성 및 메서드들을 사용할 수 있게되는 것이다.
특히, 상속받는 객체 중 하나인 Node 객체는 DOM을 조작, 조사, 탐색하는 기준이 되는 많은 속성 및 메서드들을 정의하고 있다.
결과:
Ext JS 4: The Class Definition Pipeline
Ext JS 4: The Class
Definition Pipeline
#Class 생성 전처리기
- 전처리기: 클래스 생성 준비가 완료되기까지 아래 파이프라인 절차가 실행된다.
1. define Method
define 메서드의 대표적인 기능으로 클래스 생성 및 구성 또는 정의된 네임스페이스 해석 과정등이 있다.
ExtJS4 Class System의 모든 클래스는 Ext.Class의 인스턴스이며, 시스템 공통 클래스인 Ext.Base 클래스를 상속받는다. 또한, 그(Ext.Base) 클래스는 자신의 기본 메서드인 callOverridden, callParent 등과 같은 맴버들을 하위 클래스에게 제공한다.
만약, 확장(extend) 클래스를 명시하지 않고, 신규 클래스를 정의할 경우, 클래스 정의 단계에선 Ext.Base를 상속하는 과정이 자동으로 이뤄진다.(기본적인 신규 클래스 생성 시에는 Ext.Base 공통 클래스를 자동으로 상속받게 된다)
반대로 확장(extend) 클래스를 지정한 경우에는 정의된 확장 클래스를 통해 상속 받게된다.
- 확장 클래스를 지정하지 않은 경우
- 아래 결과와 같이 ClassA 인스턴스가 생성되었고, 확장 클래스가 정의되지 않아 공통 클래스인 Ext.Base 클래스가 자동으로 할당(상속) 된것을 볼 수 있다.
- 확장 클래스(ClassA)를 지정한 경우
- 아래 결과와 같이 ClassB 인스턴스가 생성되었고, 확장 클래스(ClassA)가 정의되었으며, Ext.Base 공통 클래스는 확장 클래스(ClassA)를 통해 상속받아 확장된것을 확인할 수있다.
즉, ClassB의 __superclass__ 는 ClassA 가 된다. 또 그것의 __superclass__ 는 Ext.Base가 되는 형태이다.
2. Loader
- 각 클래스간의 종속성을 모두 파악해 필요로 하는 클래스가 모두 로드되기 전까지 지속적으로 프로세스를 수행한다.
1. ClassA.js 및 ClassB.js 파일을 생성한다.
2. app.tests.ClassB 클래스의 확장 클래스(app.tests.ClassA)를 정의하면, 시스템 전처리기 단계인 Loader 로 인해 해당 클래스를 로드하게 된다.
- 아래 결과와 같이 app.tests.ClassB 인스턴스가 생성되었고, 확장 클래스(app.tests.ClassA)가 정의되었으며, Ext.Base 공통 클래스는 확장 클래스(app.tests.ClassA)를 통해 상속받아 확장된것을 확인할 수있다.
- Loader로 인한 Deadlock 발생 원인
1. ClassA.js 및 ClassB.js 파일을 생성 후 각 클래스를 아래와 같이 정의한다.
2. app.tests.ClassA 클래스는 정의된 확장 클래스(app.tests.ClassB)를 로드 한다.
3. app.tests.ClassB 클래스는 정의된 확장 클래스(app.tests.ClassA)를 로드 한다.
4. 서로간의 클래스 종속성으로 인해 결국 클래스 로드 무한 루프가 발생하게되며, 이는 곧 Deadlock 발생에 원인이 된다.
- 아래는 Deadlock 발생 메시지에 대한 이미지이다.
3. Extend:
- 정의된 확장 클래스가 모두 로드되면, 해당 클래스를 확장시킨다.
1. app.tests.ClassB 클래스는 확장 클래스(app.tests.ClassA)로 확장한다.
2. 확장 클래스 맴버는 아래와 같이 app.tests.ClassB 인스턴스의 superclass 프로퍼티 및 prototype 맴버로 접근 가능하다.
3. 이 두 접근 객체의 차이는 superclass 프로퍼티의 경우 원본 객체의 Pointer에 직접 접근하는 반면, prototype 맴버는 확장된 자신의 프로퍼티로 직접 접근하게 된다.
즉, superclass 프로퍼티에 할당된 객체 수정 시 원본 객체의 Pointer에 접근해 수정을 할 수있는 반면, prototype 맴버에 할당된 객체는 원본 객체가 아닌 자기 자신의 맴버만 수정하게 되는것이다.
- 네이티브 자바스크립트 구현
4. Mixins
- 확장 클래스의 결합이 수행된다.(다중 상속 가능)
1. app.tests.ClassB 클래스는 확장 클래스(app.tests.ClassA)로 확장한다.
2. 확장 클래스 맴버는 아래와 같이 app.tests.ClassB 인스턴스의 mixins.classA 프로퍼티 및 prototype 맴버로 접근 가능하다.
3. 이 두 접근 객체의 차이는 mixins.classA 프로퍼티의 경우 원본 객체의 Pointer에 직접 접근하는 반면, prototype 맴버는 확장된 자신의 프로퍼티로 직접 접근하게 된다.
4. 원본 객체 접근 및 수정에 관한 내용은 위 Extend 프로퍼티 내용과 동일하다.
5. Config
- config 객체 맴버로 할당된 모든 메서드는 getter/setter 메서드들을 기본으로 가지게 된다.
- config 객체 맴버(id, name)는 아래와 같이 getter/setter 메서드들을 가지게 된다.
6. Statics
Statics 객체 맴버는 함수(클래스: ClassA) 객체 맴버로 할당되게 된다.
즉, 해당 함수 객체의 value 데이터로 할당되는것이며, 이는 타 언어의 Static 맴버와 동일하게 사용 가능하다.
- 네이티브 자바스크립트 Statics 구현
- 아래 결과와 같이 ClassA 함수 객체의 맴버로 Statics 객체 맴버로 정의된 getStaticId 메서드가 할당된것을 볼 수 있다.
#Class 생성 후처리
- 후처리기: 클래스 생성 준비가 완료된후 클래스 동작에는 영향을 끼치지 않는 파이프라인 절차가 실행된다.
1. Aliases
- 해당 클래스 네임스페이스의 별칭을 정의한다.
- ClassA 클래스 인스턴스 생성 시 기존 "ClassA" 문자열 및 아래 alias로 지정된 "_classA" 로도 생성 가능하다.
- 객체 인스턴시 생성시 결과는 아래와 같다.
2. Singleton
Singleton 프로퍼티 값을 true로 할당 시 해당 클래스의 인스턴스가 메모리상에 미리 올라가 따로 인스턴스 생성 없이 해당 객체를 바로 사용할 수 있게 된다.
즉, 타 언어의 Singleton 패턴을 자바스크립트로 구현한 방식이며, 만약 Ext.create 메서드를 통해 따로 인스턴스를 생성하려 하면 에러를 반환하게 된다.
- 네이티브 자바스크립트 Singleton 구현
3. Legacy
기존 문법과의 호환성을 위해 Ext 클래스가 대체 이름을 가질 수있게 만든다.
즉, ExtJS 이전 버전과의 문법 호환성을 위해 참조하는 클래스명을 대치시키는 것이 그중 한 부분이라할 수 있겠다.
4. Callback
- 클래스가 완전히 정의된 후 단 한번 실행하게 되는 callback 함수이다.
- 사용 범위는 극히 적을것이나, 필요시 사용 가능하다.
powerline 설치 방법(mac 기준)
1. powerline-shell(style prompt) 설치 방법
git 를 이용해 해당 소스를 다운 받은 후 아래 URL Stap에 따라 진행하면 된다.
https://github.com/milkbikis/powerline-shell
2. vim-powerline(vim editor 기준) 설치 방법
vim-vundle 을 활용해 간단히 설치할 수 있으며, 더 자세한 설명은 아래 URL을 참조하기 바란다.
http://sunyzero.tistory.com/171
http://blog.outsider.ne.kr/880
JS 객체 설계 시 This를 반환하는 이유.
Git fork, pull request 테스트
1. Mohwa 계정이 Fork 한 Mohwa2 계정의 저장소로 Pull Request 시키는 방법
최초 Mohwa2 계정의 저장소 화면.
Mohwa2 계정의 저장소(mohwa2.github.io) 화면이며, 오른쪽 상단 Fork 버튼을 통해 자신 계정의 Repository로 포함 시킨다.
저장소 Fork 후 해당 저장소(mohwa2.github.io)가 Mohwa 계정의 "Popular repositories" 리스트로 포함되어 있는걸 확인할 수 있다.(상단 4번째 리스트)
해당 저장소 상세 페이지 화면
Mohwa 계정으로 Fork된 저장소(mohwa/mohwa2.github.io)를 로컬 저장소로 clone 시킨다.
해당 저장소에 파일 생성 후 commit 단계까지 진행한다.
생성된 로컬 저장소 파일을 리모트 저장소로 push 한다.
리모트 저장소로 push 완료된 화면이며, 오른쪽 메뉴 중 pull Requests(0) 버튼을 클릭한다.
새로운 pull Request를 위해 new pull request 버튼을 클릭한다.
전송 할려는 pull Request의 제목 및 이슈 내용을 기입 후 Submit 한다.
2. Mohwa2 계정이 Mohwa 계정에게 수신한 Pull Request 를 처리(해당 branch 에 merge)하는 방법
Mohwa2 계정의 저장소 화면이며, 오른쪽 메뉴 중 pull Rrequests 버튼을 클릭한다.(pull Request 버튼의 오른쪽 카운트가 1인것을 확인할 수 있다. 이는 수신받은 pull Request count 에 대한 내역이다.)
Mohwa2 계정의 pull Request 리스트 화면이다.(mohwa 계정이 발송한 pull Request 내역을 확인할 수 있다.)
리스트 내역을 클릭 후 수신 받은 pull Request 내역을 확인 후 자신(Mohwa2 계정)의 저장소 branch(master?)로 merge 시킬수 있다.(이는 merge pull request 버튼을 통해 수행된다.)
Mohwa2 계정의 전체 pull request 내역이다.(최신 내역에 Mohwa 계정이 pull request 시킨 내역을 확인할 수 있다.)
참고: http://dogfeet.github.io/articles/2012/how-to-github.html
Git rebase 명령(커밋 수정(합치기)) 테스트
- 현재 까지 Commit 된 히스토리는 총 5개이며, "git rebase" 명령을 통해 상위 4개를(HEAD~n) 하나의 commit 으로 merge 시킬 것이다.
- 아래는 "git rebase" 명령 후 자동으로 실행되는 편집기 창이며, 해당 편집기 이용해 로드된 commit 히스토리를 수정한다.
수정방법:
- 수정하고자하는 commit index 앞의 "pick"이라는 문자열을 "squash" 라는 문자열로만 변경시켜 주기만 하면 된다.
- 수정 후 commit 히스토리를 출력한 결과이다.(이전 File1 ~ File3 파일에 대한 모든 commit 이 "f25648...a4fc" commit 으로 merge 되었다.
참고: http://dogfeet.github.io/articles/2012/how-to-github.html
Git remote fetch/pull, Git push 명령
- 리모트 저장소의 모든 자원을 "git clone" 명령을 통해 로컬 저장소로 가져온다.
- 리모트 저장소에 index2.html 파일을 추가한다.
P.S: 생성한 index2.html 파일의 Commit index는 5717f9...18a 와 같다.
- 리모트 저장소(origin) 확인 후 "git fetch" 명령을 통해 로컬 저장소 와 리모트 저장소 의 상의한 브랜치 내역을 가져온다.(로컬 저장소에는 리모트 저장소와 달리 index2.html 파일에 내한 내역은 존재하지 않는다.)
P.S: 또한, 아래 7f70cbc Commit index는 현재 리모트 저장소의 최종 Commit index인 5717f9...18a 의 parent index로 존재한다.
- "git remote fetch" 명령 수행 후 모든 영역(Working, Staging, Repository)에는 해당 파일에 대한 업데이트 내역이 존재하지 않는것을 확인할 수 있다.
하지만 실제 Git 저장소(.git/objects) 내부에는 아래 결과와 같이 index2.html 파일의 Commit index인 57/17f9...5ee4 Blob 파일이 존재하는것을 확인할 수 있다.
- 해당 Blob 파일을 확인하면, 아래와 같이 index2.html 파일에 대한 내역이라는것을 다시한번 확인할 수 있다.
- "git merge" 명령을 통해 위에서 "fetch" 된 모든 내역을 해당 로컬 Branch 에 merge 시키면, 이전 내역과 달리 모든 영역(Working, Staging, Repository)에는 현재 리모트 저장소의 업데이트 내역이 전부 반영 되어 있을 것이다.
Git remote pull
- "git remote pull" 명령은 이전 "fetch" 명령과는 달리 모든 영역(Working, Staging, Repository)에 리모트 저장소의 업데이트 내역이 존재하는것을 확인할 수 있다.(즉, "marge" 기능 까지 한번에 수행하게 된다.)
Git push
1. Workiing 영역에 index3.html 파일 생성 후 아래와 같이 모든 단계를 수행한다.
2. 리모트 저장소의 지정된 Branch로 로컬 저장소의 업데이트된 모든 내역을 Push 한다.
- 아래는 로컬 저장소로 부터 Push 된 리모트 저장소 내역이다.
참고:
Git reset 명령 테스트
Git reset --soft 옵션
1. Working 영역에 파일 생성 및 Staging 상태로 변경.
2. 파일을 저장소에 확정(Commit) 지으며, 최종 Commit 히스토리를 확인한 결과 "37c9a0478....5ee5" 가 출력된다.
3. "git reset --soft" 명령을 통해 생성된 저장소 내역을 초기화 시킨다.
- 아래 결과를 통해 "git reset --soft" 옵션에 대한 다음과 같은 특징을 알 수 있다.
1. Working 영역에는 반영되지 않는다.
2. "git ls-files -s" 결과에서와 같이 출력된 Staging 리스트 상에서 File1 파일을 확인할 수 있다.
3. "git log" 명령을 통해 최종 Commit 히스토리를 확인한 결과 위에서 출력한 Staging 리스트와 다르다는것을 알 수 있다.
4. 최종 HEAD 정보를 확인해보아도 같은 결과를 나타내며, 해당 파일을 Commit 대상으로 바라보고 있다.
- 정리하면, --soft 옵션은 Working 영역과 Staging 영역에 반영되지 않으며, Repository 영역에만 반영된다.
Git reset --mixed 옵션
- 아래 결과를 통해 "git reset --mixed" 옵션에 대한 다음과 같은 특징을 알 수 있다.
1. Working 영역에는 반영되지 않는다.
2. "git ls-files -s" 결과에서와 같이 출력된 Staging 리스트 상에서 File1 파일을 확인할 수 없다. 즉, Staging 영역에 반영되었다는것을 말한다.
3. "git log" 명령을 통해 최종 Commit 히스토리를 확인한 결과 위에서 출력한 Staging 리스트와 동일하다.
4. Staging 영역에 반영되었으므로, 파일은 현재 Untacked 상태를 나타낸다.
- 정리하면, --mixed 옵션은 Working 영역에 반영되지 않으며, Staging 및 Repository 영역에만 반영된다.
Git reset --hard 옵션
- 아래 결과를 통해 "git reset --hard" 옵션에 대한 다음과 같은 특징을 알 수 있다.
1. Working 영역에 반영된다.(파일이 존재하지 않는다.)
2. "git ls-files -s" 결과에서와 같이 출력된 Staging 리스트 상에서 File1 파일을 확인할 수 없다. 즉, Staging 영역에 반영되었다는것을 말한다.
3. "git log" 명령을 통해 최종 Commit 히스토리를 확인한 결과 위에서 출력한 Staging 리스트와 동일하다.
4. 파일 자체가 Working 영역에 존재하지 않으므로, 당연히 현재 상태 또한 존재하지 않는다.
- 정리하면, --hard 옵션은 모든 영역(Working, Staging, Repository)에 반영된다.
기본적인 Git 명령어
기본적인 Git 명령 정리 문서
Git 저장소 만들기
방법 1. "git init" 명령을 통해 해당 로컬 저장소(~/github)를 Working 영역으로 초기화 시킨다.(초기화된 Working 영역에는 ~/.git 라는 저장소 디렉토리가 생성된다.)
방법 2. "git clone remote https://github.com/mohwa/mohwa.github.io.git(리모트 저장소 URL) 명령을 통해 해당 리모트 저장소의 모든 자원을 로컬 저장소(~/github) 아래에 가져온다.(말그대로 또 다른 dummy를 생성하는 것이다.)
- "git clone" 명령은 아래와 같은 문법으로도 사용 가능하다.
git clone https://github.com/mohwa/mohwa.github.io.git aliasName(별칭)
1. Working 영역에 파일을 생성 후 파일의 현재 상태를 확인한다.(Working 영역안의 모든 자원은 "git add" 명령 수행 이전에는 모두 "Untracked" 상태를 유지하고 있는 것을 볼 수 있다.)
- 하지만 아래와 같이 "git hash-object" 명령을 수행하면, Untacked 상태임에도 불구하고, 해당 자원과 매칭된 Hash 문자열(03f128...3e9)이 미리 생성되어 있는것을 확인할 수 있다.
하지만, Hash 문자열이 미리 생성되어 있을 뿐, 실제 Tacking 되고 있는 파일과 같이 Git 저장소 내부(~/git/object) 에는 존재하지 않는다.
1. "git add" 명령을 통해 파일을 Staging 상태로 변경한다.
2. Staging 여부를 확인하기 위해 "git hash-object" 명령을 통해 해당 파일의 Hash 문자열(03f128...3e9)을 알아낸다.
3. 위에서 알아낸 파일의 Hash 문자열을 근거로 Git 저장소 내부를 확인해 본 결과 해당 위치(~/github/.git/objects/03/f128...1773e9)에 Blob 형식의 파일이 저장되어 있는 것을 확인할 수 있다.
- 또한, "git ls-files -s" 명령을 통해 현재 Staging 되고 있는 자원들의 목록을 확인할 수도 있다.
파일 변경내역 확인하기 1
1. Working 영역에 파일을 생성 후 Staging 상태로 만든다.
2. 파일 내용을 "modify File"로 변경 후 현재 Staging 여부를 확인하면, Unstaging 상태로 변경된 것을 확인할 수 있다.
- "git diff" 명령을 통해 위에서 작업한 파일들의 상태를 비교할 수 있다.(Unstaged 와 Staged 간 비교)
- 정리하면, 현재 Staging 된 파일의 Hash명은 "4de7ff....949" 이며, 파일 내용 변경 후의 Hash명은 "21cb98....e19" 라는 것을 알 수 있다.(간단히 말해, 현재 Staging 된 자원들의 목록에서 "21cb98...e19" Hash명은 찾아 볼 수 없다.)
즉, 내용이 변경된 파일은 아직 "Staging" 상태가 아닌 "Unstaged" 상태 라는 것을 확인할 수 있다.
파일 변경내역 확인하기 2
1. 현재 Staging 상태의 자원들을 출력한다.
2. Working 영역에 파일을 생성하며, 해당 파일을 Staging 상태로 변경한다.
3. "git diff --staged" 명령을 통해 현재 Staged 된 자원들과 Commit 된 자원들을 비교할 수 있다.
4. 확인 결과 최종 Commit 된 자원은 아래 index 00000..4de7ff4 와 같이 출력하고 있으며, 현재 Staging 된 자원인 File2 와 비교되는 것을 알 수 있다.
1. 파일을 Commit 단계 까지 진행시킨다.
2. 위와 마찬가지로 "git diff --staged" 명령을 통해 현재 Staged 된 파일과 Commit 된 파일을 비교하면 아무것도 출력되지 않는 것을 볼 수 있다.(이유는 현재 생성된 모든 파일이 commit 상태로 변경되었기 때문이다.)
수정하고 저장소에 저장
1. 그 동안 지속적으로 확인한 바와같이 "git commit" 명령은 현재 Staging 된 자원을 저장소에 확정시키는 역활을 수행한다.
- 위 명령과 다르게 "git commit -a -m" 명령은 변경된 파일에 대해 "git add" 명령을 생략 가능하게 해준다.
파일 삭제하기
1. "git rm" 명령을 통해 현재 Staging 되고 있는 파일을 Unstaging 상태로 변경한다.(해당 Tracking 상태는 유지하고고 있는 것을 볼 수 있다.)
파일 이름 변경
1. "git mv" 명령을 통해 파일명을 변경 시킨다.
2. 하지만 Git는 아래 결과와 같이 파일명이 변경되어도, 내용이 변경되기 전까지는 같은 Hash Point(94634...ceb50)를 가리키게 된다.
Commit 히스토리 조회
1. 모든 Commit 히스토리를 출력한다.
2. 모든 Commit 히스토리를 한줄로 출력한다.
3 모든 Commit 히스토리 중 상위 하나만 출력한다.(-num(상위 n개))
- 아래는 Commit 명령에 대한 상세 내역이다.
히스토리 수정
- 아래는 "git commit --amend" 명령 후 실행되는 편집기 화면이며, 이것을 통해 수정된다.
P.S: "git commit --amend -m "commit comment" 명령을 통해서도 수정 가능하다.
수정된 파일 되돌리기
1. 파일의 내용을 "modify File1" 로 수정한다.
2. "git checkout" 명령을 통해 수정된 파일의 내용을 되돌린다.(단, 한번 되돌리면 다신 복구가 불가능하다는 단점이 존재한다.)
3. 내용 확인 후 이전 상태로 되돌아간것을 확인할 수 있다.
리모트 저장소 확인
1. 리모트 저장소를 로컬로 가져오면, origin이라는 리모트 저장소가 자동으로 등록된다.
2. "git remote show" 명령을 통해 리모트 저장소에 대한 상세 내역을 확인할 수 있다.
리모트 저장소 추가 / 이름 변경 / 제거
- 추가
- 변경
- 삭제
태그
1. 태그 생성
- 특정 Commit 히스토리에 임의의 Tag를 지정(생성)한다.
2. 태그 내역 확인 및 삭제
- Git 기본계념과 사용법 그리고 어플리케이션:
AJ 님의 "Advanced Git" 슬라이드 Study - 4
Git Tree 객체
1. Blob + 다른 Tree 객체
2. 폴더와 같은 계념
3. .git/objects 아래 저장된다.
- 폴더는 Tree 객체로 파일은 Blob 객체로 표현된다.
- C5(다섯 번째 commit 객체)의 압축(Zlib format)된 내용을 확인 시 "404d7be....1a" 라는 해당 Tree 객체를 확인할 수 있으며, 객체(404d7be....1a) 내용 확인 시 객체(폴더) 내부에 포함된 파일들의 목록(C1 ~ C5)을 볼 수 있다.
- 하지만 아래서 보는 바와 같이 Tree 객체가 보통 파일 시스템과 같이 하나만 존재하는 것이 아닌 각 commit 객체들의 단계에 따라 지속해서 생성된다.
- C5(다섯 번째 commit 객체)에 포함된 Tree 객체 열람 시.
- C4(네 번째 commit 객체)에 포함된 Tree 객체 열람 시.
- AJ 님의 "Advanced Git" 슬라이드(참고 슬라이드)
