[Git] Git의 기초 및 Merge, Rebase, Squash에 대한 이해

Git

분산 버전 관리 시스템

• 커밋 브랜치 개념을 활용
• 각 커밋에선 데이터 스냅샷을 가지고 있음

 

#1. 커밋

프로젝트 파일의 수정을 가하여 이를 프로젝트에 적용할 때, 새로운 커밋 발생

• 각 커밋이 이전 커밋을 가리키고 있는 구조
• 아래 그림에서 98ca9, 34ac2, f30ab순으로 커밋이 생성되었음
• 커밋 과정 중 Staging Area이 있음

 

#2. 데이터 스냅샷

• 한 커밋에 대해 하나의 스냅샷 생성
• 데이터 스냅샷은 상태 변경 사항(diff)만을 저장하는 것과 다른 개념
• 데이터 스냅샷 내부엔 하위 트리 노드로 모든 파일이 blob으로 불리는 데이터 객체로 저장
• 데이터 스냅샷 내부 루트 트리는 blob들을 포인터로 가리킴

 

#3. 브랜치

• Git에서 커밋들 사이를 이동할 수 있는 포인터
• HEAD는 로컬 작업 중인 브랜치를 가리킴
• 브랜치는 하나의 커밋을 가리키는 41바이트짜리 데이터로(\n 포함한) 매우 가벼운 데이터 구조
• 다른 브랜치에서 새로운 커밋 시 프로젝트 히스토리는 갈라짐

 

Merge

두 개의 브랜치를 하나로 합치는 것

• merge 명령 수행 시 상황에 따라 크게 두 가지로 경우로 나뉨

 

#1. Fast forward

merge하는 브랜치(hotfix)가 merge되는 브랜치(master) 이후의 커밋을 가리키는 경우

• 새 커밋 생성 없이 최신 커밋으로 브랜치 포인터를 이동 수행
• 아래 그림은 hotfix를 master에 merge하는 명령 수행 과정
• 일반적으로 hotfix브랜치 포인터는 더 이상 필요없으므로 삭제

 

 

#2. 3-way

merge관계의 두 브랜치 중 하나의 브랜치가 나머지 브랜치의 조상 관계가 아닌 경우

• 두 브랜치의 공통 조상 커밋을 활용하여 새로운 커밋 생성
• 브랜치 포인터 또한 이동

만약 merge과정에서 충돌이 발생할 경우 개발자는 직접 충돌 사항을 해결해야 하며 코드 수정 후 git add -> git status(충돌 해결 여부 확인 명령어) -> git commit 명령을 통해 merge 완료

 

Rebase 

merge와 비슷한 명령을 수행, 그러나 활용 방식과 내부적인 명령 수행 과정에 차이가 있음

• 공통 조상 커밋에서 부터 지금 커밋까지의 diff 데이터를 만든 후
• rebase 명령에 포함된 두 브랜치를 합치는 과정에서 diff 데이터를 활용하여 새 커밋 생성 및 fast forward
• 커밋 히스토리가 선형적으로 보이게 됨으로 깔끔한 히스토리를 남길 수 있음

 

#1. Rebase의 장점

커밋 히스토리가 깔끔해지는 장점

프로젝트가 거대해질수록 사용되는 브랜치가 많아질 수 밖에 없는데, Rebase 활용 시 선형적으로 각 개발에 대한 커밋 히스토리를 확인할 수 있음

 

#2. Rebase 주의점

• Rebase는 브랜치를 합치는 과정에서 커밋 날짜, 커밋 메시지, 작성자가 같은 두 개의 커밋이 공존하는 상황(위 그림에서의 C4와 C4')이 있음
• 이때, 다른 개발자들의 프로젝트 pull 및 push를 진행하는 경우 커밋 히스토리가 매우 복잡해지는 문제 발생
• 따라서, Rebase는 오픈소스 프로젝트에서 적합하지 않을 수 있음

 

Squash

여러 개의 커밋을 하나의 커밋으로 묶는 것

GitHub에서 제공하는 merge기능들 중 Squash and Merge와 Rebase and Merge 두 기능의 차이를 보면 

• Squash and Merge는 병합하는 과정에서 기존 여러 커밋을 하나로 묶음
• Rebase and Merge와 달리 각 커밋 기록을 유지하지 않음

 

참고 자료

Git - 브랜치란 무엇인가

GitHub의 Merge, Squash and Merge, Rebase and Merge 정확히 이해하기 : NHN Cloud Meetup