L01 Git 기본 원리

2016.10.11(Tue)

 10월 9일 있었던 정보처리 시험과 10월 13일에 있었던 PC방 관리 프로그램 프로잭트로 인해

수업이 거의 없었고, 시험이 끝나서 게을러진 점도 없지 않아 그동안 수업 내용을 업로드 하지 못했다.

누락된 내용 전부 업데이트하고 다음주부터는 매일매일 갱신하자!!

L01 Git 기본 원리

1. Git의 데이터 관리 방식

1. Git의 데이터는 파일 시스템의 Snapshit이라 부르면 크기가 아주 작다.

2. Git은 Commit 하거나 프로젝트의 상태를 저장할 때 파일이 달라지지 않았으면 파일을 저장하지 않는다.

3. 또한 파일을 저장하는 것이 아니라 이전 상태의 파일에 대한 링크만 저장한다.

2. Local의 3가지 영역 도식도 +Git Remote repository

Git Remote reoisitory //참고만 하세요
↑git push A B	↓ git pull A B
Git Local repository(Git Directory or 로컬 저장소)
↑git commit	↓git revert c09b802
Staging Area(휴게소)
↑git add *	↓ git reset *
Working Directory(작업폴더)

• A(리모트 저장소 별칭), B(리모트 가지)

• 보통 버전 관리 시스템(Git)으로 프로젝트를 관리하면 로컬(Local repository) 영역에서 작업을 하고 작업의 결과물을 서버(Remote repository)에 올린다. 이때 여러 사람의 작업 결과물을 vranch라 하고 이를 통합(merge)하여 배포한다.

• 프로젝트의 버전 관리를 위해 git 저장소(Git Directory)에 올리거나 git에 저장된 프로젝트를 로컬(working deirectory)로 복구 시켜야 하는데 이때 중간에 다리를 하는 곳이 stage 영역이다.

• “git commit”을 하면 git 저장소에 SnapShot이 저장되는데 이 때 주소의 형식이 c09b802이다.

3. Git이 Local repository에서 동작하기 위한 세가지 영역

1. Working Directory: 수정할 파일들이 있는 디렉토리(프로젝트 실제 경로)

2. Staging Area: commit할 파일에 대한 정보를 저장한다.(git과 working directory의 중간 다리 or 임시저장소)

3. Git Directory: Git이 프로젝트의 메타데이터와 객체 데이터베이스를 저장하는 곳을 말한다. (git의 실제 저장소)

4. Git의 프로젝트 상태 관리(Commited, Modified, Staged)

1. modified: 한 번 git

add로 stage에 올라왔던 파일이 수정된 상태로 git add로 stage에 저장된 파일을 업그레이드 해야 한다.

2. staged(Change to be committed): 수정된 파일이 git add로 stage 영역에 올라와 commit 되기를 기다리는 상태

3. commited: 데이터가 Git Directory에 저장됨

5. Working Directory의 모든 파일은 Tracked와 Untracked로 나뉜다.

1. Tracked 파일은 이미 Snapshot에 포함돼 있던 파일이며, Unmodified, Modified, Staged 상태 중 하나의 상태를 갖는다.

2. Tracked 파일이 아닌 모든 파일은 Untracked 파일이다.

6. Branch(Git branch “name”)

1. 한 프로젝트를 여러 사람이 동시에 작업할 경우 코드를 여러 개 복사해야 하는 경우가 있다. 이때 branch를 사용하면 기존의 프로젝트를 기반으로 독립적인 개발이 가능해진다.

2. 개발자들은 이 branch를 나무의 가지에 비유하기 보다 Stream 즉 물줄기에 비교하고는 하는데 이는 작업의 흐름을 나무라는 큰 틀에서 뻗어 나간다는 개념 보다는 물줄기가 뻗어 나가서 다시 모이 형상과 더 어울리기 때문이다.

3. Git에서 branch는 포인터 같은 것이다.

4. 최초로 프로젝트를 Commit 하면 Git repository에 저장되는데 이때 자동으로

7. merge로 두 개의 branch를 통합하기

1. head 위치가 master이고 git merge topic이라 하면 master와 topic, 두 가지의 마지막 Commit 이력이 통합되고 master 가지는 통합된 새로운 commit을 만든다.

2. 이때 topic 가지의 head 포인터는 움직이지 않는다.

3. merge를 하면 통합되기 전 가지의 commit 이력이 그대로 남아 있다.

4. 개발자들은 master가지를 병합하기 보다 새로운 가지(topic)를 병합해서 새로운 commit 이력을 만들기를 좋아한다.

8. merge 충돌

1. 기준이 되는 가지(master)에서 다른 가지(topic)를 만들 경우 branch를 만들 당시 동일했던 내용에 변화가 생기면 충돌을 일으키게 된다.

2. Automatic merge failed는 병합 시 충돌을 의미

3. git diff 명령을 이용하면 충돌을 일으킨 위치를 찾을 수 있다.

4. git은 충돌이 일어난 위치에 <<<<>>>>와 같은 표시로 병합을 위해 수정할 것을 강요한다.

5. 병합(merge) 실패는 실제 실패를 의미하는 것이 아니다.

6. 병합을 실패하더라도 실제론 병합이 이루어진 상태이며 병합 후 commit을 대기하고 있다.

7. commit을 하지 않으면 git의 어떠한 동작도 할 수 없는 대기 상태가 되며 충돌을 일으킨 부분을 수정하고 commit을 하면 병합이 완료된다.