[Git] 초기설정 모두 완료 후 워크플로우(ebook 복습)

깃 설치나 사용자 설정, 저장소 셋팅까지 모두 끝냈다면

'워크 플로우'를 반복하면서 프로젝트를 구축할 차례입니다.

 

아래는 git ebook 에서 설명하고 있는 워크플로우입니다.

 

1. Working area의 구분

 

Local 기준, 총 3가지 장소로 나뉩니다.

Remote 까지 합하면 4개로 나눌 수 있겠네요.

 

Working Directory : 원래 작업파일. 이클립스나 안드로이드 스튜디오 등을 의미.

Staging Area : 파일을 임시저장한 경로.

.git directory : commit 정보를 SHA-1 코드로 41 바이트 크기로 저장해두는 장소.

 

remote repository 를 제외한다면 commit까지가 끝입니다.

 

해설들어갑니다.

* Working Directory -> Staging Area : git add <option> 명령어로 Stage에 Fix 할 수 있습니다.

* Staging Area -> .git directory : git commit 종류 명령어로 최종 commit 할 수 있습니다.

* .git directory -> Working Directory : 이미 commit 된 정보를 작업중인 파일로 불러옵니다.

이를 checkout 이라고 하며 일반적으로 branch 마다 commit 정보가 다르기 때문에

branch의 commit 정보를 불러온다고 생각하면 됩니다.

 

2. 실제 작업 Life cycle

 

 

위 이미지는 매우 중요합니다.

다른 작업 정보 설정이 완료됐을 때 이 그림만 이해하고 있다면

기초적인 git을 다룰 줄 아는 거라고 생각합니다.

 

프로젝트에는 여러가지 파일들이 있습니다.(class etc.)

이 파일들은 git에서 각각

Untracked / Tracked (비추적 / 추적) 혹은

Modified / Unmodified (변경된 / 변경되지 않은)

파일로 관리합니다.

 

아래는 작업 순서별로 예시입니다.

 

//

A라는 class 를 만들었습니다.

Git은 만들어진 건 알고 있지만

아직 파일의 변경요소를 추적하고 있지는 않습니다.

그래서 이 파일은 Untracked 파일입니다.

 

//

A class 의 작성이 어느정도 완료되어

Stage에 add 합니다.

Staged 파일로 분류됩니다.

 

//

Staged 된 A 파일(시점)을 완전히 commit 시킵니다.

변경사항을 모두 저장했으니 Unmodified 파일입니다.

 

//

아 그런데 A파일에 변경사항이나 확장 사항이 있습니다.

수정합니다.

Modified 파일로 분류됩니다.

 

//

파일 변경이 완료되어 다시 Stage 에 add합니다.

Staged파일로 다시 분류됩니다.

 

//

위 사항이 반복되다가

파일을 지웁니다.

지워졌으니 변경사항이 생길 일도 없습니다.

A파일은 Untracked 파일입니다.

 

3. Brach work flow

 

정말 중요한 내용 중 하나입니다.

위 내용이 git이 파일을 어떻게 분류하고 관리하는지에 대한 설명이라면

아래는 프로젝트의 시점을 저장하는 branch 의 cycle 입니다.

 

3-1. 기본 master branch 에서 C0 시점부터 시작하여 commit 을 2회 한 모습입니다.

3-2. issue 가 생겨 임시 branch를 생성함과 동시에 checkout까지 합니다.

branch생성 시 자동으로 최신 commit 정보를 반영합니다.

참고로 HEAD라는 포인터는 iss53 branch를 바라봅니다.(checkout 됐으니까)

 

 

3-3. 임시 branch에 checkout 한 상태로 새로운 commit 을 합니다.

아래에서 issue 를 해결하기 위해

iss53 branch에는 메서드를 하나 추가했다면

당연히 master 브랜치에는 그 메서드가 없습니다.

iss53 branch만 한 단계 더 나아갔습니다.

 

 

 

3-4. 여기서 새로운 긴급 오류가 생겨서 C2를 참조하는(C3는 다른 issue 해결을 위한 별도의 branch이므로)

새로운 branch를 만든다고 해보자.

$git checkout master

$git branch -b hotfix

 

이제 C2를 참조하는 brach 가 2개가 되었다.

 

3-5. Fast forward

 

hotfix branch가 성공적이어서 merge를 한다.

$git checkout master

$git merge hotfix

(덮어쓰기 당하는 브랜치로 checkout하고

덮어쓸 업데이트 파일을 merge한다.)

위는 master 브랜치에 hotfix 브랜치의 변경사항을

merge하는 것이다.

 

단, 아래의 경우는 단지 시점을 앞으로 이동하는 것에 불과하기 때문에

(master+a)

Fast forward 라고 부른다.

 

이제 hotfix branch는 의미가 없어졌으므로

$git branch -d hotfix 로 삭제해준다.

 

 

3-6. merge

hotfix branch가 마무리되어서 지웠죠?

원래 진행하던 iss53 branch로 돌아갑니다.

master branch는 Fast forward 된 채로 둡니다.

C2를 분기로 해서 여전히 갈려져있습니다.

 

iss53 도 진척이 있어서 새로운 commit 을 실행했습니다.

 

3-7. 3 way merge

 

Fast forward 와는 다르게 C5는 C3가 조상이고 C4는 C2가 조상이기 때문에

master branch에 checkout 하고 merge시키면 Fast forward가 아니라 3 way merge가 됩니다.

 

Git이 자동으로 공통 조상을 찾아서

공통조상 branch / checkout 한 branch / merge 할 branch

위 3 way branch merge를 한 후

아예 새로운 commit 정보를 만든다.

그리고 checkout 되어있던 branch가 새로운 merge commit 을 가리키도록 한다.

 

 

 

이제는 iss53 branch 또한 필요없어졌으므로

$git branch -d iss53 해준다.