[GIT] branch_merge 실습으로 이해하기(2)

싹 날리고

Git init : 저장소 생성(.git 디렉토리 생성)

 

1. f1.txt : a라고 기입 파일 생성

2. git add : 파일을 커밋 대기상태로 바꾸고 stage area에 들어간다.

3. git commit : 대기상태인 파일을 커밋하고 버전생성이됨.

4. f1.txt : b 문구를 추가하고 저장.

5. git commit –am : add 생략하고 커밋(신규파일은 add 생략안됨. Add를 꼭 해줘야함)

 

* git log

1. Author : 버전을 작성한 사람의 정보

2. Date : 언제 버전을 만들었는지

3. 맨아래 1 이라는 버전의 메시지 정보를 볼 수 있다.

 

* 브랜치를 써야할 때

1. 고객사 만을 위한 기능을 작업할 때

2. 필요없는 기능같은데 개발하려고 할 때

3. 테스트 기능을 만들 때

 

 

git branch : 생성된 브랜치를 보여준다.

> 깃은 처음 사용할 때 기본 master 브랜치를 사용하게 한다. 앞에 *은 현재 사용하고 있는 브랜치를 표시함.

 

1. git branch 브랜치명 : 브랜치명으로 브랜치를 생성한다.

 

1. git checkout 브랜치명 : 기존 브랜치에서 체크아웃 나가고 새로운 브랜치로 접속

 

git log로 히스토리를 보면 master와 exp 브랜치는 같은 상태라는 것을 알 수 있다.

> 브랜치를 생성하면 가지고 있던 브랜치를 그대로 복사한다는 것을 알 수 있다.

 

1. f1.txt를 수정 후 커밋 후 히스토리보기

 

1. checkout 으로 브랜치를 변경하고 히스토리 및 파일내용 확인

exp 브랜치로 변경하고 히스토리 및 파일 내용을 보면 다른 것을 확인할 수 있다.

 

exp 브랜치에 파일을 생성하고 커밋

브랜치를 변경하면 파일이 없고, 다른 브랜치에는 있다.

 

1. git log –branches –decorate : 브랜치별 히스토리를 보여달라.

2. HEAD : 현재 접속되어 있는 브랜치

3. exp : exp브랜치의 최신커밋

4. master : master브랜치의 최신 커밋

 

앞에 빨간 줄 > 이렇게 이어져어 왔다.

 

1. master 브랜치에 f3.txt파일을 생성하여 내용 a 기입 후 커밋

 

1. 좌측 빨간줄과 녹색줄을 잘봐야함

> 1,2,5 커밋은 master에서 이루어진 것이고

> exp브랜치는 2에서 비롯되었으며 3,4의 커밋을 거쳤다.

> HEAD : 현재 접속되어 있는 브랜치

 

한줄로 한결하게 보여짐.

이런걸 보여지게 하는 GUI 툴이 많다. 적절한 걸 사용해보자. Ex) stree

1. git log exp..master : exp에는 없고 master에 있는 것을 보여달라

2. git log –p exp..master : exp에는 없고 master에 있는 것을 소스와 함께 보여달라

 

1. git diff master..exp

> --- a/f1.txt : master파일

> +++ b/f1.txt : exp 파일

> a b : master f1.txt에는 ab만 있는데

> +c : exp에는 c 내용이 추가되었다.

2. master에는 f3.txt가 있고, exp에는 f2.txt가 있다.

 

git merge : exp에서 작업한 내용을 master로 병합

 

노란 문구 : exp를 master로 병합하겠다는 의미의 디폴트 메시지 변경해도됨.

Wq로 저장

 

1. 브랜치 로그 확인

2. HEAD : 현재 브랜치는 mater

2. Merge branch ‘exp’ : 아까 작성한 디폴트 메시지 > 이것이 master의 최신 커밋

> exp 에서 작업한 4번과, master에서 작업한 3,5번을 부모로 갖는다. 즉 4번이 마지막 exp 커밋 파일 5번이 없다.

 

git branch –d exp : exp 브랜치 삭제

git branch –D exp : 강제삭제

 

Exp는 사라지고 master만 남은 것을 확인할 수 있다.

 

깃 매뉴얼 오픈북으로 만듬 추후 정독 추천

 

Master 브랜치에서 어떤 사람이 3번 커밋했다고 가정.

이상태에서 이슈가 발생했다. 예를들면 버그수정

 

버그를 수정하기 위해 브랜치를 생성한다.

그렇게 되면 c2커밋을 master와 iss53이 동시에 가르키게 된다.

 

그 상태에서 소스를 수정하면 iss53은 c3를 가르킨다.

 

Iss53을 수정하던 도중 다른 문제가 생겨 브랜치를 생성하여 커밋을 하게되면 위와 같은 그림이 생성된다. 그리고 hotfix가 급한 것이기 때문에 hotfix를 master로 병합을 하면

 

그러면 위처럼 fast-forward(빨리감기) 라는 메시지가 뜬다.

> master 브랜치를 hotfix 브랜치로 병합한다.

> master 브랜치가 가르키는 commit을 hotfix가 가르키는 commit으로 빨리감기를 한다는 의미

 

Fast-forward 그러면 master브랜치는 hotfix 브랜치의 c4커밋을 가르키게 된다. 그렇기 때문에 별도의 commit을 생성하지 않는다. 이것을 fast forward라고 함.

 

Hotfix가 끝났으면 hotfix 브랜치를 지우고 iss53을 처리해야 한다.

 

그렇다면 그림은 위처럼 된다.

 

Iss53 작업이 끝나면 위처럼 master브랜치로 변경하여 merge를 진행한다.

Recursive strategy : c4와 c5를 합쳐 새로운 commit을 생성함 > 머지커밋

 

 

C6는 c4와 c5에 의해 만들어진 버전임을 알 수 있다.

 

* git branch 충돌해결

1. 브랜치 생성

2~3. Master.txt 소스 작성

4. 이 파일을 커밋 대기상태로 바꾸고 stage area에 들어간다.

5. 커밋 대기상태인 파일을 커밋하고 버전생성이됨. 그리고 local repository에 버전관리가 됨

 

1. exp branch로 변경

2. common.txt 소스파일 생성

3. 이 파일을 커밋 대기상태로 바꾸고 stage area에 들어간다.

4. 커밋 대기상태인 파일을 커밋하고 버전생성이됨. 그리고 local repository에 버전관리가 됨

5. master 브랜치로 변경

6. exp 브랜치에서 작업한 내용을 master 브랜치로 병합

메시지 적고 wq 저장 생략

7. exp와 master모두 common.txt 파일이 생성되었다.

 

1. exp 브랜치로 변경

2. common.txt 소스변경

3. 커밋대기상태 및 커밋

4. master 브랜치로 체크아웃

 

마스터와 exp 브랜치가 common.txt를 서로 다르게 수정해서 커밋했다.

 

마스터와 exp에서 작성한 내용이 둘다 자동으로 적용했다.

정말 좋은 기능이지만, 같은 부분을 수정할 때 불행해진다.

 

마스터와 exp 브랜치의 소스가 서로 다른 것을 알 수 있다. 왜냐하면 exp소스는 master에 병합했는데, master 소스는 exp로 병합히지 않았기 때문이다.

 

exp브랜치에 master브랜치를 병합하면 비로소 일치하게 된다.

 

1. master 브랜치의 소스 a펑션 인자값 수정

2. 스테이징 area에 커밋 대기상태 및 커밋

3. exp 브랜치로 변경

4,5. common.txt 소스 a펑션 인자값 수정

6. 스테이징 area에 커밋 대기상태 및 커밋

7. master브랜치로 변경

8. master 브랜치에 exp브랜치를 병합

9. both modified : 둘 다 같은 곳이 수정되어 병합에 실패했다는 메시지

 

master에서 common.txt 파일을 열면 위처럼 나온다.

1. ======= : 구분자

2. <<<<<<< HEAD : 현재 접속하여 있는 브랜치(즉 master)

3. >>>>>>> exp : exp 브랜치의 내용

> 깃이 사용자에게 이부분이 충돌났으니 해결하라는 표시임.

 

1. Common.txt 파일을 적절히 수정

2. 다시 커밋대기상태 스테이징에어리어에 올림

 

Exp와 머지를 한것이라는 메시지를 디폴트로 작성해줌.

Conflickts 에러가 났던걸 수정했다는 메시지를 보여줌.

 

잘 처리가됨

머지 비교를 쉽게하는 오픈소스도 있음. kdiff3 이란게 있다 나중에 써보자

 

* 2way merge : base가 없다고 생각해보자 > 1번라인 : Me와 Other 브랜치가 다르므로 뭐가 맞는지 알 수 없다. > 2번라인 : 모두 같으므로 B > 3번라인 : Me와 Other 브랜치가 다르므로 뭐가 맞는지 알 수 없다. > 4번라인 : Me와 Other 브랜치가 다르므로 뭐가 맞는지 알 수 없다. * 3way merge : Base가 있다. > 1번라인 : Base와 A가 같으므로 수정자는 Other이므로 Other이 맞다. 이처럼 알수있다.

Stash : 감추다 숨겨두다란 뜻 > 하나의 브랜치에서 신나게 작업을 하다가 다른 작업이 생겨서 다른 브랜치를 생성해야할 때, 작업이 끝나지 않아 커밋을 할 수 없는 상황. 커밋을 안하면 체크아웃을 할 수 없는 경우에 stash를 활용한다. 작업한 내용을 숨겨놓을 수 있다.

저장소 초기화함.

 

1. 소스파일을 생성

2. staging area에 커밋 대기상태로 전환

3. 커밋

4. exp 브랜치를 생성하고 exp 브랜치로 전환

5. 소스파일 수정 a 한칸띄고 b 입력함

6. 수정하다 말고 체크아웃을 하게되면

7. status를 찍어보면 exp 브랜치에서 작업한 f1.txt 가 master에 영향을 준다는 메시지

 

다시 exp 브랜치로 돌아왔지만 여전히 문제는 남아있다. 커밋하기도 체크아웃하기도 뭣한 상황

 

git stash 혹은 git stash save

working directory의 내용과 index의 내용이 Save 저장됨 exp에

> WIP : Working In Process 작업중

 

1. git status : 아무것도 커밋할 것이 없다는 메시지

2. 즉 f1.txt는 작업한 내용을 가지고 있지 않은 상태가 된다.

3. checkout도 무리없이 진행되어 master브랜치에서 작업이 가능하다.

 

1. 브랜치 변경

2. git stash apply : 감추어 두었던 소스를 다시 불러온다.

> 그럼 다시 modified 상태가 되어 수정했던 소스가 불러와진다.

 

1. git stash list : 임시저장한 내역을 보여줌

2. git reset –hard HEAD : 가장 최신에 커밋한(HEAD)로 롤백(이러면 작업한 걸 잃어버린걸까?)

 

1. 롤백하여도 stash list에 내역이 남아있다.

2. git stash apply : 이를 통해 임시저장 내역 중 가장 최신 것을 다시 불러와 modified 상태로 돌아옴

> stash를 통해 임시저장한 파일은 롤백을 하더라도 살아있다.

 

1. 다시 롤백

2~4. f2.txt 파일 생성 및 staging area에 커밋대기상태로 만듬

5. git stash : working directory의 내용과 index의 내용이 Save 저장됨 exp에

 

S2개의 stash가 저장되었으며, tash는 위에것이 가장 최근에 수정된 것..

Stash(0) : 가장 최근에 수정된 것()

Stash(1) : 그 이전에 임시저장소에 저장된 것

 

1. 가장 최신 것으로 임시저장을 해도

2. stash에 기록이 남아있다.

3. git stash drop : stash 중 가장 최신 것을 지운다.

4. stash 리스트를 확인하면 최신께 지워지고 하나만 남은 것을 볼 수 있다.

5. 2번째로 임시저장한 것을 현재 소스에 적용하고 stash drop

> 2번째로 임시저장한 f2.txt 파일 생김, f1.txt가 수정중인 내역이 나온다.

 

Stash 리스트를 봐도 이젠 stash 내역이 없어진 것을 확인할 수 있다.

1. 파일이 새로 생성되거나 수정중인 파일이 있음을 확인

2. 롤백

3~5. 소스 수정 및 staging Area에 배포대기 상태로 변경

6, 7. git stash 로 임시저장하고 status를 확인하면 stash가 없음을 확인 할 수 있다.

8. git stash pop : 스태쉬가 apply되고 드랍을 한번에 해준다.

 

1. 롤백

2,3. 소스 수정

4. 신규파일 생성 내용은 a 라고 적음

5. git status를 보면 f1.txt는 수정 중 f2.txt는 신규 파일임을 알 수 있다.

 

이럴 때 git stash로 임시저장을 해도 f2.txt는 추적되지 않는다고 메시지를 보여준다.

> 즉 stash를 하려면 최소한 버전관리를 하고 있는(add 이상) 파일 중에 사용할 수 있다.