반응형
GitLab의 Merge 3가지 정책에 대해서 배워보겠습니다.
Merge Request - Merge 정책 3가지
- Merge Commit
- Merge Commit with semi-linear history
- Fast-Forward merge
현재 커밋 로그 (가정)
현재 커밋 로그가 위 사진과 같다고 생각해보고 3가지 정책을 실행해 보도록 하겠습니다.
1. Merge Commit
우리가 흔히 알고 있는 Merge 입니다.
- 특징
- commit history 모양에 상관없이 항상 Merge가 허용됩니다.
- 항상 새로운 commit을 생성하면서 Merge가 이뤄집니다.
- 장점
- 어디서 branch가 갈라졌고, 어디서 합쳐졌는지 빠짐없이 기록됩니다.
- 전체 작업의 정확한 history를 볼 수 있습니다.
- 단점
- 개발 규모가 커지면 history가 엄청나게 복잡해집니다.
develop 브랜치에서 Func-A 브랜치를 머지하게 되면, 새로운 커밋이 생성되고 Merge가 이루어지게 됩니다.
2. Merge commit with semi-linear history
이 정책은 커밋 히스토리가 마치 semi-linear(직선) 하다고 해서 붙여진 이름이라고 합니다.
- 특징
- Fast-forward Merge가 가능한 경우에만 Merge를 허용합니다.
- 하지만, 실제로는 1번 정책과 같은 새로운 commit을 생성하여 Merge가 이뤄집니다.
- 장점
- semi-linear 한 형태의 히스토리가 깔끔하게 남기 때문에 한눈에 알아보기 편합니다.
- 단점
- Merge가 허용되지 않을 때는, Rebase 작업을 해줘야합니다.
Merge가 허용된 경우
1번 정책과 결과물 같음.
Merge가 허용되지 않는 경우
현재 상황은 Fast-Forward가 불가능하기 때문에 Merge가 허용이 되지 않습니다.
이때 필요한 작업이 바로 Rebase 입니다.
Rebase 하기
Rebase는 출발점을 재설정하다 라는 의미를 가집니다.
Func-B 브랜치를 develop 브랜치 뒤로 rebase 작업을 진행한 결과입니다.
이렇게 되면 이제 Fast-Forward Merge가 가능해졌고, 아래와 같이 Merge가 실행될 것입니다.
3. Fast-Forward Merge
- 특징
- Fast-Forward가 가능한 경우에만 Merge를 허용합니다.
- 실제 Merge도 Fast-Forward 방식으로 진행됩니다.
- 장점
- 완벽한 일직선의 history로 정말 깔끔합니다.
- 단점
- 어디서 branch가 갈라졌고 합쳐졌는지 알 수 없습니다.
- Merge가 허용되지 않을 경우에 마찬가지로 Rebase를 해줘야 합니다.
반응형
