Github에서 pullRequest를 날릴 때 유심히 살펴보면, 아래와 같은 Merge 전략을 확인할 수 있다.
위 사진으로 확인할 수 있듯이, merge 전략에는 세 가지 방법이 있다.
- Create merge commit
- Squash and merge
- Rebase and merge
여기에서 먼저 git Merge의 세가지 방법들을 살펴보기 위해서는 우선 git Commit에 대한 이해가 필요하다
Commit이란 - 파일이나 폴더의 추가, 변경사항을 저장소에 기록하는 행위를 뜻한다.
그리고 이러한 Commit들이 쌓여서 커밋 히스토리를 만들게 되는데, 이 커밋 히스토리를 통해 저장소 내에서 어떤 작업들이 이루어졌는지에 대해서 알 수 있게 된다.
이렇게 서로다른 세 가지 방법들을 사용하는 이유는 Commit messeage, Commit graph를 어떻게 유지해야 할지와 연관되어 있기 때문이다.
Merge
- 일반적으로 많이 사용하는 merge 방법이며 커밋 이력을 모두 남길 때 사용
- 장점이자 단점은 모든 커밋과 분기했던 branch들의 히스토리가 남게된다.
1. Fast-forward 설정 -ff
- merge의 기본 설정값
- 분기점인 base브랜치가 분기 이후 커밋된 내용이 없는 최신 브랜치 일 경우 분기된 대상 브랜치를 병합하고 커밋 히스토리를 남긴다.
- 어떤 branch에서 만들어져서 왔는지 아주 상세히 파악 가능
Github의 Merge pull request는 git merge -—no-ff 옵션으로 Base 브랜치가 최신 브랜치라 할지라도 커밋을 남기도록 강제합니다.
2. Squash & Merge -squash
- 분기했던 branch에 있는 커밋의 내용들을 모두 합쳐 하나의 새로운 커밋을 만든다.
- 지저분한 커밋 히스토리를 하나로 합쳐서 의미 있는 하나의 커밋으로 정리할 때 사용한다.
- 기본 변경사항들이 어떻게 변했는가 보다 merge가 되었다에 더 집중한 전력
- 남아있는 정보량이 적어지기 때문에 언제 어떤 코드를 변경했는지에 대한 정보를 잃을 수 있다.
3. Rebase & merge
- 최초 base에서 분기했던 branch를 base로 변경하고 merge 하는 방법이다.
- rebase를 하면 커밋들의 base가 변경돼 커밋 해시 또한 변경될 수 있다.
- merge 이력을 남길 필요가 없는 경우 사용
- 커밋그래프가 하나의 라인으로 나타나 가독성에 좋다. = 3 way merge를 계속하다 보면 로그 보기가 힘들어짐
참고
- https://ssocoit.tistory.com/
- 코드잇 제공 자료
