GIT 브랜치

브랜치: 코드를 통째로 복사하고 나서 원래 코드와는 상관없이 독립적으로 개발을 진행할 수 있는데, 

이렇게 독립적으로 개발하는 것이 브랜치다.

 

커밋하면 Git은 현 Staging Area에 있는 데이터의 스냅샷에 대한 포인터, 저자나 커밋 메시지 같은 메타데이터,

이전 커밋에 대한 포인터 등을 포함하는 커밋 개체(커밋 Object)를 저장한다. 

이전 커밋 포인터가 있어서 현재 커밋이 무엇을 기준으로 바뀌었는지를 알 수 있다. 

최초 커밋을 제외한 나머지 커밋은 이전 커밋 포인터가 적어도 하나씩 있고 브랜치를합친 Merge 커밋 같은 경우에는 이전 커밋 포인터가 여러 개 있다.

 

파일을 Stage하면 Git 저장소에 파일을 저장하고(Git은 이것을 Blob이라고 부른다) 

Staging Area에 해당 파일의 체크섬을 저장한다

 Git의 브랜치는 커밋 사이를 가볍게 이동할 수 있는 어떤 포인터 같은 것이다.
기본적으로 Git은 master 브랜치를 만든다. 처음 커밋하면 이 master 브랜치가 생성된 커밋을 가리킨다. 이후 커밋을 만들면 master 브랜치는 자동으로 가장 마지막 커밋을 가리킨다.

* 모든 저장소에서 “master” 브랜치가 존재하는 이유는 git init 명령으로 초기화할 때 자동으로
만들어진 이 브랜치를 애써 다른 이름으로 변경하지 않기 때문이다.

---

<새 브런치 생성하기>

git branch testing      #testing이라는 이름의 브랜치 생성

새로 만든 브랜치도 지금 작업하고 있던 마지막 커밋을 가리킨다.

 

브런치를 생성하기만 하면 Git은 아직 master 브랜치를 가리키고 있다. 

git branch 명령은 브랜치를 만들기만 하고 브랜치를 옮기지 않는다.

git log --oneline --decorate  #HEAD 포인터가 어떤 브랜치를 가리키는지 확인 가능

* HEAD: 지금 작업하는 로컬 브랜치를 가리키는 포인터

<브랜치 이동하기>

git checkout testing  #HEAD는 testing 브랜치를 가리킨다.

git checkout -b testing  #브랜치를 만들면서 그 브랜치로 이동까지 하는 명령

 

 

ㄴ

이상태에서 커밋을 하나 하면 아래와 같다.

앞으로 커밋을 하면 다른 브랜치의 작업들과 별개로 진행되기 때문에 testing 브랜치에서 임시로 작업하고 

원래 master 브랜치로 돌아와서 하던 일을 계속할 수 있다.

 

* 브랜치를 이동하면 그 브랜치에서 가장 마지막으로 했던 작업 내용으로 working 디렉토리의 파일이 변경된다. 

 

다시 master 브랜치로 와서 파일을 커밋하면 아래와 같다.

프로젝트 히스토리는 분리돼 진행한다. 두 작업 내용은 서로 독립적으로 각 브랜치에 존재한다. 

 

실제로 Git의 브랜치는 어떤 한 커밋을 가리키는 40글자의 SHA-1 체크섬 파일에 불과하기 때문에 만들기도 쉽고
지우기도 쉽다. 새로 브랜치를 하나 만드는 것은 41바이트 크기의 파일을(40자와 줄 바꿈 문자) 하나 만드는 것에
불과하다.
브랜치가 필요할 때 프로젝트를 통째로 복사해야 하는 다른 버전 관리 도구와 Git의 차이는 극명하다. 통째로 복사하는작업은 프로젝트 크기에 따라 다르겠지만 수십 초에서 수십 분까지 걸린다. 
그에 비해 Git은 순식간이다. 게다가 커밋을 할 때마다 이전 커밋의 정보를 저장하기 때문에 Merge 할 때 어디서부터(Merge Base) 합쳐야 하는지 안다. 

---

<브랜치 합치기>

git checkout master  #마스터 브랜치로 이동하고 
git merge hotfix    #합치기

Fast-forward

*hotfix 브랜치가 가리키는 C4 커밋이 C2 커밋에 기반한 브랜치이기때문에 

브랜치 포인터는 Merge 과정 없이 그저 최신 커밋으로 이동한다. 

이런 Merge 방식을 “Fast forward” 라고 한다.

git branch -d hotfix   #merge했으니깐 필요없는 hotfix 브랜치 삭제하기

master와 별개로 진행하는 iss53 브랜치

*만약  iss53 브랜치에서 hotfix 변경사항을 포함하여 작업하고 싶다면

git merge master 명령으로 master 브랜치를 iss53 브랜치에 merge하면 iss53 브랜치에 hotfix가 적용된다.

 

이제 그림같은 상황에서 iss54과 master를 merge하려한다면

git은 각 브랜치가 가리키는 커밋 두개와 공통 조상 하나를 사용하여 3-way Merge를 한다.

c6이 Merge 커밋

3-way Merge 의 결과를 별도의 커밋으로 만들고 나서 해당 브랜치가 그 커밋을 가리키도록 이동시킨다.

이런 커밋은 부모가 여러 개고 Merge 커밋이라고 부른다.

 

* 가끔씩 3-way-Merge가 실패할 때도 있다. Merge하는 두 브랜치에서 같은 파일의 한 부분을 동시에 수정한 상태라면 git은 해당 부분을 Merge하지 못한다.  이런 상황을 충돌했다고 한다. 

충돌을 개발자가 해결해야 Merge가 가능. 어떤 파일에서 충돌이 났는지 살펴보려면 git status 명령을 이용한다.

충돌이 일어난 파일은 unmerged 상태로 표시된다.

충돌을 해결하려면 위쪽이나 아래쪽 내용 중 골라서 새로 수정해야 한다.

---

<브랜치 관리>

1. git branch 명령을 아무 옵션 없이 실행하면 존재하는 브랜치들의 목록을 보여준다.

* 기호가 붙어있는 브랜치는 현재 작업하는 브랜치를 나타낸다.

2. git branch -v 명령을 실행하면 브랜치마다 마지막 커밋 메시지도 함께 보여준다.

3. git branch --merged: 현재 Checkout 한 브랜치를 기준으로 Merge 된 브랜치를 확인

*기호가 붙어있지 않은 브랜치는 삭제해도 되는 브랜치다.(이미 다른 브랜치와 Merge 했기 때문에)

git branch --no-merged: 현재 Checkout 한 브랜치를 기준으로 Merge 안 된 브랜치를 확인

Merge 안된 거라 git branch -d 명령으로 삭제되지 않는다.

*강제로 삭제하고 싶다면 -D 옵션으로 삭제한다.

 

특정 브랜치를 기준으로 확인하고 싶다면 명령에 브랜치 이름을 지정해주면 된다.

master 브랜치를 기준으로 확인