1. branch merge 방법
merge
두 브랜치의 변경 사항을 모두 유지하면서 병합하는 방법이다.
모든 변경 사항을 유지하기 때문에 커밋 히스토리가 복잡해질 수 있다.
Squash and merge
분기했던 브랜치에서의 모든 변경 사항을 하나의 커밋으로 압축하여 병합하는 방법이다.
커밋 히스토리를 간단하게 유지할 수 있지만 작업의 상세한 이력을 잃어 추후 문제 해결이 어려울 수 있다.
Rebase and merge
분기했던 branch의 기준을 최신 Base로 설정하고, merge하는 방법이다.
깨끗하고 선형적인 커밋 히스토리를 만들어주지만 관련된 커밋의 ID들이 모두 바뀌게 되어 혼란이 생길 수도 있다.
2. Git Flow 브랜치 전략
Git Flow는 크게 main 브랜치, develop 브랜치, supporting 브랜치로 구분하여 브랜치를 관리한다. 여기서 supporting 브랜치는 또 다시 feature 브랜치, release 브랜치, hotfix 브랜치로 나뉜다.
main 브랜치
정식 배포의 기준이 되는 브랜치로, 항상 안정적인 제품이 서비스될 수 있는 소스코드이며, 언제나 배포 가능한 상태로 유지되어야 하는 브랜치이다.
develop 브랜치
다음에 배포할 것을 개발하는 브랜치이다. 개발이 완료되면, main 브랜치로 merge 된다.
develop 브랜치는 통합 브랜치의 역할을 하며, 평소에는 이 브랜치를 기반으로 개발을 진행한다.
feature 브랜치
개발할 기능을 위한 브랜치이다. develop 브랜치에 기존에 잘 작동하는 코드가 담겨있으면 feature 브랜치에는 새로 변경될 코드를 분리하고 보존하는 역할을 한다. 따라서 기능 개발이 완료되면 그 변화가 develop 브랜치로 merge하고 feature 브랜치는 제거된다.
release 브랜치
배포를 위한 브랜치이다. 배포 전 마무리 작업과 버그 수정이 이루어집니다. 완료되면 mian과 develop 브랜치로 merge 한다.
hotfix 브랜치
긴급한 버그 수정을 위한 브랜치이다. master 브랜치에서 발생한 버그를 고치고 main과 develop 브랜치로 merge 한다.
