공부 기록
[Git] 브랜치(branch) 본문
✅ 들어가며
Git과 Github를 사용할 때 branch를 생성하여 프로젝트를 진행한 적이 없다.
이번 프로젝트에서는 branch를 생성하여 작업해보려고 하는데 그전에 branch의 개념과 사용방법에 대해 먼저 공부해보려고 한다.
✅ 브랜치
📌 브랜치(branch)란?
브랜치(branch)는 개발을 할 때 코드를 통째로 복사한 후 원래 코드와는 상관없이 독립적으로 개발을 진행하는 것을 말한다.
📌 브랜치 사용의 장점
- 한 소스코드에서 동시에 다양한 작업을 할 수 있다.
- 소스코드의 한 시점과 동일한 상태를 만들고, 브랜치를 넘나들며 작업을 수행할 수 있다.
- 각각의 브랜치에서 생긴 변화가 다른 브랜치에 영향을 주지 않고 독립적으로 코딩할 수 있다.
즉, 브랜치를 생성하여 작업하게 되면 편리하게 협업할 수 있다.
📌 브랜치 종류
Main branch : 중앙 저장소에 항상 유지되는 메인 브랜치
1. Master branch
- 제품으로 출시될 수 있는 브랜치
- 배포 이력을 관리하기 위해 하용한다. 즉, 배포 가능한 상태만을 관리한다.
2. Develop Branch
- 다음 출시 버전을 개발하는 브랜치
- 기능 개발을 위한 브랜치들을 병합하기 위해 사용한다. 즉, 모든 기능이 추가되고 버그가 수정되어 배포 가능한 안정적인 상태라면 develop 브랜치를 master 브랜치에 merge(병합)한다. 평소에 이 브랜치를 기반으로 개발을 진행한다.
Supporting branch : 일정 기간 동안만 유지되는 보조 브랜치
1. Feature branch
- 기능을 개발하는 브랜치
- 새로운 기능 개발 및 버그 수정이 필요할 때마다 develop 브랜치로부터 분기한다. feature 브랜치에서의 작업은 공유할 필요가 없기 때문에 로컬 저장소에서 관리한다.
- 새로운 기능에 대한 작업을 수행한 후 작업이 끝나면 develop 브랜치로 merge 한다.
- 브랜치가 많은 경우 작업에 혼란을 줄 수 있으므로 더 이상 필요하지 않은 feature 브랜치는 삭제한다.
2. Release branch
- 출시 버전을 준비하는 브랜치
- release 브랜치는 배포를 위한 최종적인 버그 수정, 문서 추가 등 배포와 직접적으로 관련된 작업을 수행한다. 이 외의 작업들은 release 브랜치에 추가로 merge 하지 않는다.
3. Hotfix branch
- 출시 버전에서 발생한 버그를 수정하는 브랜치
- develop 브랜치에서 문제 부분을 수정하여 배포 가능한 버전을 만들기에는 시간도 많이 소요되고 안정성을 보장하기 어려우므로 master 브랜치에서 직접 브랜치를 만들어 필요한 부분만 수정 후 다시 master 브랜치에 병합하여 배포한다.
- hotfix 브랜치에서의 변경 사항은 develop 브랜치에도 merge 한다.
📌 브랜치 네이밍
| 종류 | 명명 규칙 | 예시 |
| master | 본래 이름 사용이 일반적 | master |
| develop | 본래 이름 사용이 일반적 | develop |
| feature | feature/기능요약 feature/{issue-number}-{feature-name} (이슈추적 사용의 경우) |
feature/login feature/1-init-project |
| release | release-RB... 또는 release-... 또는 release/... release-... 형식을 추천 |
release-1.2 |
| hotfix | hotfix-... | hotfix-1.2.1 |
✅ 나가며
취업 후 프로젝트를 진행할 경우 시스템의 규모도 크고 함께 협업하는 개발자도 많을 것이다.
협업을 잘해나가기 위해서 브랜치 사용 방법을 잘 익혀두어야겠다.
참고자료
'프로그래밍 > Git' 카테고리의 다른 글
| [Git] 깃 커밋 메시지 컨벤션(Git Commit Message Convention) (0) | 2024.01.24 |
|---|