[Github] merge, squash, rebase

목적

협업 시 github의 커밋내역을 효과적으로 관리하기 위함

목차

1. merge
2. squash
3. rebase

1. merge

한 브랜치를 다른 브랜치와 합치는 방법이다.

master브랜치가 원본 브랜치이고, feature/test브랜치가 master에서 파생된 브랜치라고 가정해보자.

이때 master브랜치에 merge를 하게 되면 기존 master브랜치의 커밋내역(m0, m1, m2, m3)에 추가적으로 feature/test에서 작업했던 커밋내역(ft1, ft2, ft3)가 합쳐진다.

master브랜치의 커밋내역에 feature/test의 커밋내역이 더해져 총 커밋 내역은 m0, m1, m2, m3, ft1, ft2, ft3 와 같이 생성된다.

2. squash

한 브랜치와 다른 브랜치는 합치는 방법인 것은 merge와 동일하다.

하지만 작업한 커밋 내역을 없애고 새로운 커밋 내역을 만든 뒤 merge하게 되는 방법이다.

master브랜치가 원본 브랜치이고, feature/test브랜치에 master에서 파생된 브랜치라고 가정해보자.

이때 master브랜치에 squash and merge를 하게 되면 기존 master브랜치의 커밋내역(m0, m1, m2, m3)에 feature/test에서 작업했던 내역들(ft1, ft2, ft3)에 대해 한 개의 커밋으로 대체된다.

기존 feature/test의 커밋내역은 무시되고 새로운 커밋 하나만 더해져 총 커밋 내역은 m0, m1, m2, m3, ft4 와 같이 생성된다.

3. rebase

파생된 브랜치의 원본이 되는 브랜치에서 커밋이 발생한 경우 원본 브랜치의 커밋을 파생된 브랜치의 이전 커밋으로 끌고오는 방법이다.

master브랜치의 m1에서 파생된 feature/test브랜치가 존재한다고 가정해보자.

feature/test브랜치에서 작업하는 동안(ft1, ft2, ft3) master브랜치 역시 작업(m2, m3, m4)이 발생하였다.

이때 rebase를 하게 된다면 feature/test의 기존 base는 m1이였는데 base가 m4로 변경되며 이전 master의 작업 내역들(m2,m3,m4)가 모두 feature/test의 이전 커밋내역으로 들어오게 된다.

3가지 방법 모두 소스 충돌에 잘 대처해야 한다.