02. 깃 (Git) - [기본] 브랜치

OS	Windows 10 Home 64bit 버전 1903 (OS 빌드 18362.836)
Git	git version 2.9.0.windows.1

 

# 시작전

이전 01.깃 (Git) - [기본] 버전 관리 에서 했던 내용이 전부 지워주세요

 

# 브랜치의 기본 개념

브랜치는 보통 나뭇가지라고 설명하는 데, 물의 흐름이라고 생각하면 이해하기 더 쉽다.

나뭇가지는 뻗어나가면 다시 합쳐지지 않지만 물은 상류에서 뻗어지다가 결국에는 바다로 합쳐진다.

개발 중에는 여러사람이 만들기 때문에 여러 갈래로 뻗어나가지만, 결국 서버를 띄울 때는 합쳐지기 때문이다

브랜치	설명
master (마스터)	제품으로 출시될 수 있는 브랜치
develop (디벨럽)	다음 출시 버전을 개발하는 브랜치
feature (퓨처)	기능을 개발하는 브랜치
release (릴리즈)	이번 출시 버전을 준비하는 브랜치
hotfix (핫픽스)	출시 버전에서 발생한 버그를 수정 하는 브랜치

 

브랜치의 종류는 회사마다 위 브랜치가 더 적을수도 더 많을 수도 있다.

기본 규모가 작은 프로젝트에서는 master 와 develop 2개로 나뉘어 사용하고,

조금 더 크면 master 와 develop, tset 하는 브랜치를 사용한다. 

대규모 프로젝트 같은 경우 브랜치가 그 이상일 수 있다

( 롤 이라는 게임에서는 버그발생 시 되돌리는 작업을 rollback 또는 hoffix 라고 한다 )

 

브랜치의 자세한 개념은 아래 사이트 참고 바람

우린 Git-flow를 사용하고 있어요 - 우아한형제들 기술 블로그

 

# 01. 브랜치 만들기

$ git brunch // 브랜치 목록 보기

$ git brunch 브랜치명 // 브랜치 생성

브랜치 설명위한 밑 작업

 

커밋된 로그

 

브랜치 목록 보기

 

브랜치 추가 및 목록보기

 

4개 브랜치 모두 최신 커밋에 위치

 

work.txt 편집

 

content4 추가

 

master 에서 커밋

 

master 브랜치만 최신 커밋인 work 4 에 있다.

 

$ git log --oneline // 깃 로그 간단히 보기

$ git log --oneline

 

 

$ git checkout 브랜치명 // 브랜치 바꾸기

브랜치가 app 으로 전환된 모습

 

커밋 로그 확인

 

app 에서는 master 의 work 4 커밋이 안보인다

 

work.txt 내용 또한 content4 가 없다

 

work.txt 편집

 

content4 내용 추가

 

add, commit

 

로그를 보면 app 브랜친만 최신 커밋에 위치한다

git log --branches // 모든 브랜치 포함한 로그

git log --oneline --branches // 모든 브랜치 포함한 간단 로그

 

$ git log --oneline --branch --graph // -- 모든 브랜치를 포함한 간단 로그 + 그래프

왼쪽의 빨간 직선과 대각선을 보면  work 3 이후로 2가지로 분리됬다는 의미이다

 

$ git log 브랜치1..브랜치2 // 브랜치1 에는 없고, 브랜치2 에 있는 브랜치2 커밋내용만 표시

mater 에만 있는 work 4만 표시된다

 

#02. 브랜치 병합하기

$ git init 디렉토리명 // 디렉토리를 생성 후, 해당 디렉토리 안에서 버전관리를 한다

m2 에 만들어지는 모습

 

m2 디렉토리로 이동 - 다른 버전관리로 오면서 기본 1개밖에없는 master 로 자동으로 브랜치가 바뀐다

 

work.txt 생성

 

1 작성

 

add 와 commit 을 해준다

 

o2 브랜치 생성

 

master.txt 생성

 

master 2 으로 저장

 

add, commit

 

o2 로 브랜치 변경

 

o2.txt 생성

 

o2 저장

 

add commit

 

로그 보기

 

 

o2 브랜치의 내용을 master 브랜치로 병합하기

master 브랜치로 전환

 

$ git merge 브랜치명

master 와 o2 병합하기

 

병합 메시지 내용

[참고] 병합할 때 메시지 지정문구를 나오지 않게하려면 아래와 같이 사용하면된다

$ git merge 브랜치명 --no-edit // <-> $ git merge 브랜치명 --edit

 

 

병합 완료

 

master 브랜치 로그 보기

 

o2 브랜치로 변경

 

o2 의 로그 보기

 

브랜치 포함 로그 보기

master 는 o2 의 커밋을 병합하면서 가장 최근 커밋으로 Merge branch o2 가 생성되었다.

병합하면서 master 는 o2 브랜치가 가지고 있던 02 work 2 커밋을 갖게되었다.

반면, o2 브랜치는 master 의 커밋 내용을 갖고있지는 않는다

 

같은 문서를 서로다른 위치를 수정했을 때 병합하기

- A.txt 를 master 브랜치도 수정했고, o2 라는 브랜치도 수정했을 때 상황이다

cd ..

 

m3 디렉토리에서 버전관리

 

m3 디렉토리로 이동

 

work.txt 생성

 

내용 저장

 

add, commit

 

o2 브랜치 생성

 

master 에서 work.txt 수정

 

master work 2 내용 추가 후 저장

 

commit

 

o2 브랜치로 변경

 

o2 브랜치에서 work.txt 수정

 

ow work 2 내용 추가 후 저장

 

commit

 

master 브랜치에서 병합하기 위해 master 로 브랜치 변경

 

master 에서 o2 와 병합

 

병합 완료된 모습

 

work.txt 내용보기

다른 브랜치에서 같은 파일을 수정한 후 merge 하면 해당 브랜치가 수정했던 내용도 반영이 된다

 

같은 문서의 같은 위치를 수정했을 때 병합하기

m4 를 생성해주세요 (만드는 법은 생략)

 

work.txt 생성

 

내용 추가 후 저장

 

add, commit

 

o2 브랜치 생성

 

master 에서 work.txt 수정

 

3번째 줄을 11111 로 수정 후 저장

 

commit

 

o2 브랜치로 변경

 

o2 에서 work.txt 수정

 

3번째 줄을 22222 로 수정 후 저장

 

commit

 

master 에서 merge 하기 위해 master 브랜치로 변경

 

master 브랜치에서 o2 브랜치 병합하기

 

같은 줄을 수정한 경우 Auto-mergin 이라는 문구가 뜬다

 

work.txt 내용보기

 

vim 에서 <<<, ===, >>> 을 지워주고 저장한다 (a 오타는 그냥 넘어가요)

 

commit

 

로그보기 - 병합 충돌났을 때의 커밋은 존재하지 않는다

 

병합이 끝난 브랜치 삭제하기

삭제를 해도 다시 같은 이름으로 생성하면 이전의 내용을 재확인 가능하다

기본 브랜치는 master 이기 때문에 master 브랜치에서 작업을 해야한다

브랜치가 master 가 아닌 경우 $ git checkout master 입력 바람

 

$ git branch -d 브랜치명 // 브랜치 삭제

o2 브랜치 삭제

 

브랜치 목록 보기

 

#03. 브랜치 관리하기

cd ..

 

m5 버전관리

 

cd m5

 

work.txt 생성

 

1 작성 후 저장

 

add, commit

 

브랜치 생성

 

master 에서 work.txt 수정

 

2를 추가후 저장

 

add, commit

 

sub 브랜치로 변경

 

sub 브랜치에서 work2.txt 생성

 

1 sub 으로 입력 후 저장

 

add, commit

 

sub 에서 로그 보기

브랜치가 여러개일 때도 현재 브랜치가 아닌 다른 브랜치에 있는 커밋을 골라서 최신 커밋으로 지정할 수 있다

sub 에서는 mater 커밋인 'e8efe93 master work 2' 가 존재하지 않는다.

존재하지 않아도 e8efe93 을 가지고 해당커밋으로 되돌아갈 수 있다

 

$ git reset 브랜치별 커밋해시 // 모든 브랜치의 커밋중 원하는 커밋지점으로 돌아갈 수 있다

git reset

 

sub 에서 로그보기

 

sub 에서 work.txt 내용보기

 

$ git checkout -- work.txt 로 한다면 

기존의 master 커밋이였던 work.txt 내용 1,2으로 바뀐다

 

커밋이 되돌아가면 작업트리 영역은 그대로 남아있기 때문에 수정이 되어있다

 

수행 중인 파일 감추기 및 되돌리기

브랜치에서 파일을 수정하고 커밋하지 않은 상태에서 급하게 다른 파일을 커밋해야 할 경우 사용한다

조건, 한 번은 커밋한 상태 tracked 상태여야 한다

 

m6 버전관리 생성 (생성방법은 생략하겠습니다)

 

work.txt 생성

 

1 작성 후 저장

 

add, commit

 

work2.txt 생성

 

2 입력 후 저장

 

add, commit

 

현재 존재하는 파일과 git 상태보기

 

work.txt 수정

 

modified 추가 후 저장

 

work2.txt 수정

 

modified 추가하고 저장

 

git status 로 상태확인 - 작업트리에서 2개의 파일이 수정되었음을 감지하였다

 

$ git stash // 스테이징 영역 숨기기

작업트리의 수정내용 숨기기

 

git status 로 상태 확인 - 숨기기했기 때문에 스테이징에 add 하라는 말이 사라졌다

 

$ git stash list // 숨긴 내역들 보기

stash@{0} 에는 work.txt 와 work2.txt 변경내용들이 담겨있다

 

 

cat 으로 work.txt, work2.txt 보기 - 아까 수정했던 내용을 stash 로 숨겼기 때문에 원래의 내용으로 돌아와졌다

 

work2.txt 수정하기

 

modified modified 추가 후 저장

 

수정을 하고나면 git stash 숨기기를 할 수 있다.

방금 work2.txt 수정내용을 숨긴 stash는 stash@{0} 이다

work.txt 와 work2.txt 수정내용을 숨긴 stash 는 stash@{1} 로 된다.

 

$ git status pop // 가장 최근에 저장된 stash 가져오기 (stash 영역 에서 해당 statsh 삭제)

git status pop 으로 가장 최근에 숨겼던 내용을 보이게한다

 

 

stash 영역에는 가져왔기 때문에 총 개수가 1개만 된다

 

commit

 

 

 

$ git status apply // 가장 최근에 저장된 stash 가져오기 (stash 영역에서 해당 stash 삭제 안함)

auto merging 이 된 이유는

stash 영역에 stash@{0} 은 commit work 2 이 였을 때다

하지만 현재 commit work 3 에 위치하기 때문에

내용이 달라져서 stash 에서 가져올 때 auto merging 이 이루어졌다

 

work2.txt 내용 보기

 

pop 과 다르게 stash 는 삭제되지 않았다

 

$ git status drop // 가장 최근에 저장된 stash 삭제

가장 최근 stash 삭제

 

stash 가 삭제된 모습