git에서 branch merge, git flow

코드잇 2023. 12. 8. 20:24

branch merge

GitHub에서 3가지의 merge 방식이 있다.

merge commit은 두 브랜치의 변경사항을 유지하면서 병합합니다. 이를 통해 프로젝트의 진행상황을 명확하게 이해하고 추적할 수 있습니다. 다만 커밋 히스토리가 복잡해진다는게 단점입니다.

Github의 Merge pull request는 git merge --no--ff 옵션으로 Base 브랜치가 최신브랜치라 할지라도 커밋을 남기도록 강제 한다.

- ff (fast-forward)

Squash and merge는 브랜치의 모든 과정을 하나의 브랜치로 압축하여 병합하는 방법입니다. 커밋 히스토리를 간단하게 유지할 수 있다는 장점이 있지만 작업의 상세한 이력을 잃게 됩니다.

git merge에 -squash 옵션을 추가한 방법입니다.

Rebase and merge는 현재 브랜치를 target 브랜치에 재위치 시켜 병합하는 방법입니다. 깨끗하고 선형적인 브랜치로 만들 수 있지만 커밋 id가 모두 바뀌어서 혼란을 초래할 수 있습니다.

git merge --ff 와 같은 형태가 된다.

git merge --ff : git merge는 --ff 옵션이 기본으로 설정 되어있다. 변경 내용이 없는 최신 브랜치일 경우 병합한다는 커밋 없이 합치고, 그렇지 않으면 병합 커밋을 남긴다.

git-flow에는 5가지 종류의 브랜치가 존재합니다. 항상 유지되는 메인 브랜치들(master, develop)과 일정 기간 동안만 유지되는 보조 브랜치들(feature, release, hotfix)이 있습니다.

- master : 제품으로 출시될 수 있는 브랜치

- develop : 개발 중인 코드를 관리하는 브랜치. 배포 작업이 시작 될 수 있는 브랜치 입니다.

- feature : 기능을 개발하는 브랜치. 기능 개발이 완료되면 develop 브랜치로 병합하고, feature 브랜치는 제거됩니다.

- release : 배포를 위한 브랜치. 배포 전 마무리 작업과 버그 수정이 이루어집니다. 완료되면 master와 develop 브랜치로 병합됩니다. 릴리즈가 끝나면 브랜치는 제거 됩니다.

- hotfix : 긴급한 수정을 위한 브랜치. master 브랜치에서 발생한 버그를 고치고 mater와 develop 브랜치로 병합합니다.

git flow는 안정적인 코드 배포를 위한 강력한 전략이지만, 작은 규모의 프로젝트에서는 비효율적일 수 있습니다.

배포주기가 긴 대형 서비스이며, 서비스의 안전성이 강조되는 경우에 좋은 전략이 될 수 있다.

참고 자료