Git과 Github에 대하여 (feat. Merge VS Rebase)

1. Git이란?

Git은 코드나 소스파일을 버전별로 관리할 수 있는 버전 관리 시스템(VCS) 중 하나이다.

Git은 자신이 관리하는 영역의 모든 파일들의 변경사항을 추적한다.

 

Git은 변경사항 뿐 아니라 작업한 사람, 날짜 등을 추적할 수 있어서

협업 시 효과적으로 코드를 관리할 수 있으며 여러 사람들과 동기화가 가능하다는 장점이 있다.

 

코드와 소스파일을 버전별로 관리하기 때문에 특정 시점(버전)으로 롤백이 가능해서

자유롭게 기능을 개발하고 테스트 할 수 있다.

무엇보다 파일에 문제가 발생했을 때 원인을 파악하고 해결하는 대에 매우 편리하다.

---

2. Git의 구성 요소

1) Working Directory

Git이 관리하는 파일들이 존재하는 영역으로 .git 디렉토리를 제외한 모든 파일들이 포함된다.

이 영역의 파일에서 변경이 발생되면 그 파일은 수정된(modified) 상태로 변경된다.

2) Staging Area

수정된 파일의 변경사항을 버전에 반영(commit)하기 전에 임시로 저장해놓는 공간이다.

수정된 파일들 중에서 버전에 포함되길 원하는 파일을 선택하거나 제거하는 용도로 사용된다.

이 영역에 파일을 등록하는 작업을 "staging" 이라고 한다.

3) Local Repository

staging한 파일들을 버전별로 저장하고 관리하는 공간이다.

파일을 스냅샷 형태로 저장해놓고 스냅샷과 비교하여 파일의 변경사항을 추적한다.

변경사항이 새로운 버전에 반영된 파일들은 다시 Working Directory로 돌아간다.

Local Repository에 파일을 추가하거나 변경사항을 저장하는 작업을 Commit이라고 한다.

---

3. Github란?

클라우드 시스템을 통해 로컬 저장소(Local Repository)를 원격 저장할 수 있는 서비스

코드를 백업하거나 다른 사람과 공유할 때 주로 사용한다.

---

4. Merge VS Rebase

둘 다 공통 조상을 갖는 서로 다른 branch를 병합한다는 공통점이 있지만 분명한 차이가 있다.

1) Merge

Fast-Forward Merging과 3-Way Merging이 있다.

Fast-Forward 방식은 단순히 branch의 HEAD만 옮겨 작업을 완료하지만

3-Way 방식은 두 branch에서 변경이 발생한 파일(commit)을 수동으로 작업해줘야 한다.

 

Merge는 합병 후 새로운 commit(merge commit)이 생성되고,

각 branch에서 발생한 commit log를 그대로 가져오기 때문에

지속적으로 하나의 branch로 merge가 발생할 경우 히스토리가 매우 복잡해진다는 문제가 있다.

 

이 문제를 해결할 때 사용하는게 rebase이다.

2) Rebase

rebase는 뜻 그대로 베이스를 재설정한다는 의미이다.

branch는 베이스를 갖고 있고 그 베이스를 다른 branch의 최신 커밋으로 옮긴다.

rebase 전과 후

feature branch의 베이스를 master로 재설정한 결과이다.

f1, f2 commit은 베이스가 재설정됐기 때문에 기존과 아예 다른 hash값을 가진다.

 

이 상태에서 feature를 master로 merge하면 Fast-Foward Merging이 일어나며

master branch는 commit log가 순차적으로 정렬된 상태가 된다.

---

참고 문서

https://hajoung56.tistory.com/5

[GIT] git merge와 git rebase의 차이