무하프로젝트

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

- 현재 까지 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 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 --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 저장소 만들기

방법 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 기본계념과 사용법 그리고 어플리케이션:

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" 슬라이드(참고 슬라이드)

Git 저장소 파일 분석(Blob 형식)

1. Header 형식을 포함하여 Zlib으로 압축되어 저장된다.

- Header 형식: "Blob/원본 파일크기/null" > "blob(객체 종류) 11(원본 파일 크기)\x00(null 바이트) some-value\n"

- 실제 이전 포스트에서 생성된 C1(첫 번째 commit 객체)에 대한 파일 뷰는 아래와 같다.

- Git는 내부에서 생성되는 모든 파일을 단순 이름이 아닌 SHA-1 Hash(902640....8a) 방식으로 저장한다. 이는 16진수 문자로 조합된 40개의 문자열로 파일의 내용 및 해당 디렉터리 구조를 바탕으로 구성되어진다.

- 보안 상 오직 Git를 통해서만 원하는 파일에 접근 및 수정이 가능하다.

- AJ 님의 "Advanced Git" 슬라이드(참고 슬라이드)

Git HEAD Pointer 및 Branch Pointer 설명

1. Git 명령의 대부분은 File 보다는 Commit 객체를 다룬다.

2. Git 에서의 HEAD와 Branch는 Pointer임을 기억하자.

1. C1(첫 번째 commit 객체) 생성 후 HEAD Pointer 및 Branch Pointer의 변화

- C1(첫 번째 commit 객체) 생성 후 HEAD Pointer는 기존 master Branch를 가리키며, 해당 branch(master) Pointer는 C1(첫 번째 commit 객체) Pointer를 가리킨다.

2. C2(두 번째 commit 객체) 생성 후 HEAD Pointer 및 Branch Pointer의 변화

- C2(두 번째 commit 객체) 생성 후 HEAD Pointer는 기존 master Branch를 가리키며, 해당 branch(master) Pointer는 C2(두 번째 commit 객체)를 가리킨다.

3. C3(두 번째 commit 객체) 생성 후 HEAD Pointer 및 Branch Pointer의 변화

- C3(세 번째 commit 객체) 생성 후 HEAD Pointer는 기존 master Branch를 가리키며, 해당 branch(master) Pointer는 C3(세 번째 commit 객체)를 가리킨다.

4. 새로운 Branch(develop)를 생성 후 HEAD Pointer 및 Branch Pointer를 각각 develop Branch와 C2(두 번째 commit 객체)를 가리키도록 만든다

HEAD > develop Branch

develop Branch > C2(두 번째 commit 객체)

- AJ 님의 "Advanced Git" 슬라이드(참고 슬라이드)

Git 저장소 분석

- Git 저장소는 아래와 같은 구조로 구성되어있다.

1. Working 영역(작업 폴더)

- "git init" 명령 실행 후 ".git" 파일이 저징되어 있는 위치를 가리킨다.

2. Staging 영역

Working 영역(작업 폴더)에 임의의 파일(Readme)을 생성 후 "git add ." 명령을 통해 Staging 영역으로 추가 시킨다.

또한, Working 영역의 Readme 파일은 "Blob" 형식으로 변환되어 아래 경로(.git/objects/3e/d8....79)에 저장되며, 파일의 실제 내용은 "Zlip(데이터 압축 라이브러리의 일종)"으로 압축되어 있다.

git add . 명령은? 

- Git로 하여금 앞으로 이 파일을 Tracking 하겠다는 선언이며, 다른 VCS(Version Control System) 시스템과는 달리 "commit" 단계가 아닌 "add" 단계에서 저장소에 파일이 생성되는 것을 볼 수 있다.

3. Repository 영역

"git commit" 명령을 통해 이전 Staging 영역에 등록된 리스트를 참조(add 명령을 통해 이미 Staging 영역에 파일이 등록되어 있기 때문)하여 새로운 "commit object"를 생성한다.

또한, 생성된 "commit object"는 아래 경로(.git/objects/48/c468937...72)에 저장되며, "Zlip"을 통해 압축된 내용을 확인 시, 아래와 같이 "Tree, Author, Committer, Commit msg" 가 담긴 내용을 확인할 수 있다.

.git/refs/heads/master 파일은 아래와 같이 "486893....72" commit object 객체를 가리키고 있다.

4. 두 번째 commit object 생성 후 HEAD 변화

- 위 과정을 통해 두 번째 "commit object" 까지 생성하게되면, 이전 "486893....72" 객체를 가리키던, .git/refs/heads/master 파일은 새로운 commit object인 "786481...60" 객체를 가리키게 된다.

이는 "git branch -v" 명령을 통해서도 확인 가능하다.

5. Git 저장소 내부 파일의 Status Life Cycle은 아래 같으며, 보시는 바와같이 파일의 Untrancked 시점과 Tracked 시점은 Git add 전/후로 나눠진다.(중요!!)

출처: http://www.slideshare.net/andabi/git-16126636

- AJ 님의 "Advanced Git" 슬라이드(참고 슬라이드)