본 포스트는 Git Book 과 책 모두의 깃&깃허브를 참고하여 작성되었습니다.
Branch란
Git에서 말하는 Branch는, 마치 나뭇가지와 같이 버전을 여러 흐름으로 관리하는 방법을 뜻한다.
Branch의 필요성을 쉽게 이해하기 위해 Branch가 없는 상황을 가정해보기로 한다.
A와 B가 협업하여 온라인 쇼핑몰을 만들었다.
쇼핑몰은 어느정도 완성된 상태로, 코드는 방대하고 commit이 꽤 쌓여있는 상태이다.
A와 B는 여기에 "장바구니" 기능과 "주문 목록 기능"을 각각 추가하기로 하였다.
A와 B는 각자 맡은 기능을 local에서 구현한 뒤 하나로 합쳐야 한다.
이 경우 어쩔 수 없이 A와 B는 각자가 추가하고 수정한 코드를 하나하나 대조해봐야 한다.
A와 B가 작업한 내용 중에는 서로의 작업과 전혀 관련 없는 부분도 있을 것이고,
때로는 같은 코드를 다르게 수정한 부분도 있을 것이다.
이를 일일히 대조하고 합칠 코드를 판단하는 것은 너무나 번거롭고,
수작업으로 합치는 과정에서 중요한 코드가 손실될 수도 있다.이와 같은 상황은 Branch를 활용하면 쉽게 해결할 수 있다.
어느 정도 완성된 쇼핑몰에서 각자의 Branch를 나눈 뒤, 각자의 작업이 끝나면 A와 B의 Branch를 하나로 합친다. 이 경우엔 같은 파일을 다르게 수정한 부분만 살펴보면 된다.
Branch를 나누는 방법
Branch를 나눌 때 사용할 수 있는 전략은 Git Flow 전략과 Github Flow 전략이 있다. 두 방식의 차이는 다음과 같다.
Git Flow
복잡한 개발환경을 컨트롤 할 수 있는 체계적인 branch 관리 전략
구조화된 방식이 필요할 때 사용
브랜치 구조
| Branch 명 | 용도 |
|---|---|
| main | 배포용 Branch (항상 안정적인 상태) |
| develop | 개발이 진행되는 Branch, 개발이 완료되면 release에서 test |
| feature/<기능명> | 기능 개발 Branch, 개발이 완료되면 dev에 병합 |
| release/<release 번호> | 배포 준비 Branch, 배포 준비가 완료되면 main에 병합 |
| hotfix/<수정사항> | 긴급 수정 Branch, 수정 완료시 main과 dev에 병합 |
Github Flow
단순한 프로젝트를 컨트롤 할 때 유용한 효율적인 branch 관리 전략
빠르고 유연한 작업이 필요할 때 적합
브랜치 구조
| Branch 명 | 용도 |
|---|---|
| main | 유일한 영구 Branch이자 배포용 Branch (항상 안정적인 상태) |
| feature(이름은 자유) | 특정 기능을 개발하는 Branch, 이름은 자유롭게 정함 |
Git Flow vs GitHub Flow 비교
| 항목 | Git Flow | GitHub Flow |
|---|---|---|
| 브랜치 구조 | 다중 Branch (master, develop, feature/*, release/*, hotfix/*) | 단일 영구 Branch(main) + 임시 브랜치 |
| 복잡성 | 상대적으로 복잡 | 단순하고 직관적 |
| 배포 방식 | 배포 전 release에서 테스트 | main 병합 후 즉시 배포 가능 |
| 주요 장점 | 안정성과 체계적 관리 | 빠른 개발과 배포 |
| 주요 단점 | 느린 배포 속도, 관리 복잡 | 낮은 안정성 |
| 적합한 팀 규모 | 대규모 팀 | 소규모 팀 |
| 적합한 프로젝트 | 안정성과 체계가 중요한 장기 프로젝트 | 빈번한 배포가 필요한 애자일 프로젝트 |
Branch를 병합하는 방법
간단한 명령어를 통해 로컬에서 바로 병합할 수 있다.
예시: feature/home을 develop에 병합
git checkout develop -- base가 될 branch로 이동
git merge feature/home -- branch 병합다만 팀 프로젝트에선 Pull Request(PR)을 사용하는 편이 권장된다. 병합 전에 팀원들이 코드의 품질을 확인할 수 있으며, 변경 내용과 의도를 명시할 수 있기 때문이다.
02/대학생