branch merge 방법
1. fast-forward
메인브랜치에 신규 커밋이 없는 경우. 그냥 브랜치의 최신 커밋을 main브랜치로 하기로 한다.
fast-forward는 가장 기본적인 머지 방법으로, 서로 다른 두 개의 브랜치가 같은 조상을 갖고 있으면서 한쪽 브랜치만 커밋 이력이 있을 경우 사용합니다.
브랜치를 서로 병합할 때 새로운 커밋을 만드는 것이 아닌 HEAD를 옮기는 방법이기 때문에 히스토리를 깔끔하게 관리할 수 있다는 장점이 있지만 언제 병합했는지 확인하기 어렵다는 단점 또한 갖고 있습니다.
2. 3-way merge
브랜치마다 신규 커밋이 하나 이상있는 경우!
새로운 커밋을 생성하며 합쳐준다.
3 way merge란 base 브랜치를 참고해서 다른 두 개의 브랜치를 비교하는 방법입니다.
서로 다른 두 브랜치 중 한 명만 파일 수정을 했을 때 파일을 수정한 사람의 파일만을 머지하여 conflict를 내지 않고,
두 브랜치가 같은 파일을 수정했을 때 둘 다 머지를 하여 충돌된 부분을 해결 후 커밋합니다.
3 way merge는 2 way merge보다 conflict를 최소화하는 특징을 갖고 있기 때문에 3 way merge 방법을 사용하는 것이 더 좋습니다.
Git Flow 브랜치 전략
git 브랜치 전략은 브랜치를 효율적으로 관리하기 위한 워크플로우.
그 중 대표적인것이 git flow 전략.
- main : 라이브 서버에 제품으로 출시되는 브랜치. 배포된 버전을 tag를 사용하여 표시합니다.
- develop : 다음 출시 버전을 대비하여 개발하는 브랜치.
- feature : 추가 기능 개발 브랜치. develop 브랜치에 들어간다.
- release : 다음 버전 출시를 준비하는 브랜치. develop 브랜치를 release 브랜치로 옮긴 후 QA, 테스트를 진행하고 main 브랜치로 합친다.
(출시된 main 브랜치에 버전 tag 추가) - hotfix : main 브랜치에서 발생한 버그를 수정하는 브랜치.
메인 브랜치
항시 유지되는 main 브랜치와 develop 브랜치 두 종류를 말한다.
main 브랜치는 배포 가능한 상태만을 관리하는 브랜치를 말하며,
develop브랜치는 다음에 배포할 것을 개발하는 브랜치이다.
즉 develop 브랜치는 통합 브랜치의 역할을 하며, 평소에는 이 브랜치를 기반으로 개발을 진행한다.
보조 브랜치
새로운 기능을 추가할 때 주로 사용하는 가지이다.
merge 되면 사라지는 보조 브랜치 feature, release, hotfix 3가지로 구성된다.
🔗 참고 블로그
