이전 포스트에서 깃(Git), 깃허브(GitHub)에 대해서 정리해보았다. 공부하던 중, GitHub 활용법이 헷갈리는게 많아 한 번 정리해야겠다 싶어서 정리해본다.
📌Git - 브랜치(Branch)란?
브랜치(Branch) 란 한 마디로 정리하자면
독립적으로 어떤 작업을 수행하기 위해 만들어 주는 것
이다.
위 그림에서 파란색으로 'Your Work' 라고 되어있는 원들과 주황색으로 'Someone Else's Work'라고 되어있는 원들은 Master로부터 나온 연두색 원들의 흐름에서 중간에 잠시 빠져나와 만들어지고 다시 그 흐름으로 들어간다. Branch 는 위와 같은 형태로 나와 다른 사람 두 명이 동시에 개발하는 것이다. 정리하면,
- Branch는 사용자가 독립적으로 작업을 수행할 수 있도록 돕는 작업 흐름이다.
- 하나의 브랜치는 독립된 워크스페이스, 인덱스, 로컬 리포지토리, 리모트 리포지토리 공간을 갖는다.
- 실제로 개발자 A, B가 작업을 한다고 하면, A가 먼저 작업을 마무리 하고, B가 작업을 이어서 하는 것이 아니라 A, B가 동시에 자기 작업 파트를 개발한다.
- 이러한 경우 깃에서 Branch는 여러 작업을 각각 독립된 공간에서 진행할 수 있도록 돕는다. 즉, 하나의 프로젝트에서 여러 사람이 동시에 본인의 작업을 진행할 수 있다.
브랜치를 이용한 작업 흐름
- 위 그림과 같이 각 개발자는 메인 브랜치에서 자신이 작업할 새로운 브랜치를 만든다.
- 각 개발자는 자신이 만든 브랜치 위에서 작업한 후에, 리모트 리포지토리(GitHub 등)에 자신이 작업한 브랜치를 Push하고,
- 리모트 리포티조티레엇 메인 브랜치로 Pull Request 한 후, 다른 개발자들에게 리뷰를 받는다.
- 리뷰가 완료되면 메인 브랜치에 Merge 한다.
이해를 돕는 또 다른 사진이 찾아서 첨부한다.
다른 버전 관리 도구들은 변경이 필요할 때, 프로젝트를 통째로 복사해야 하는 것과 비교하여 Git은 순식간이다. 또한, 커밋 할 때마다 커밋의 정보를 저장하기 때문에 Merge 할 때 어디서부터 합쳐야하는지 안다. 이것이 개발자가 브랜치를 사용하게 만드는 이유이기도 하다.
📌Git - 다섯 가지 종류의 브랜치(Branch)
(사실 브랜치의 종류를 알아보려 한 것은 Feature 가 뭔지를 몰라서 시작되었다. 자꾸 블로그들이나 듣고 있는 패캠 강사님이 Feature를 만들어주겠다 그래서... Feature 라는게 있는건가?(브랜치가 뭔지도 아예 모를 때) 해서 구글링해봤는데 Feature Branch 라는게 있는 거고, 이는 Branch의 종류들 중 하나임을 알았다. 엄청 멍청이에서 멍청이가 된 순간!!!^^)
브랜치에는 다음 그림과 같이 다섯 가지 종류가 있다.
크게 메인 브랜치인 Master, Develop 브랜치와 /// 보조 브랜치인 Feature, Release, Hotfix 브랜치로 나눌 수 있다.
1. Master Branch
제품으로 출시될 수 있는 브랜치.
배포(Release) 이력을 관리하기 위해 사용. 즉, 배포 가능한 상태만을 관리한다.
2. Develop Branch
다음 출시 버전을 개발하는 브랜치.
기능 개발을 위한 브랜치들을 병합하기 위해 사용.
모든 기능이 추가되고 버그가 수정되어 배포 가능한 상태가 되면 Develop Branch를 Master Branch에 병합(merge) 한다.
평소에는 이 브랜치를 기반으로 개발을 진행한다.
3. Feature Branch
기능을 개발하는 브랜치.
새로운 기능 개발 및 버그 수정이 필요할 때마다 Develop Branch로부터 분기한다.
Feature Branch에서의 작업은 기본적으로 공유할 필요가 없기 때문에 자신의 로컬 저장소에서 관리한다.
개발이 완료되면 Feature Branch를 Develop Branch로 병합(merge)하여 다른 사람들과 공유한다.
더 이상 필요하지 않은 Feature Branch 는 삭제한다.
4. Release Branch
이번 출시 버전을 준비하는 브랜치.
배포를 위한 전용 브랜치를 사용함으로써 한 팀이 해당 배포를 준비하는 동안 다른 팀은 다음 배포를 위한 기능 개발을 계속할 수 있다. 즉, 딱딱 끊어지는 개발 단계를 정의하기 아주 좋다.
1. Develop Branch에서 배포할 수 있는 수준의 기능이 모이면 또는 정해진 배포 일정이 되면, Release Branch를 분기한다.
- Release Branch를 만드는 순간부터 배포 사이클이 시작된다.
- Release Branch에서는 배포를 위한 최종적인 버그 수정, 문서 추가 등 릴리스와 직접적으로 관련된 작업을 수행한다.
- 직접적으로 관련된 작업들을 제외하고는 Release Branch 에서 새로운 기능을 추가로 병합(merge) 하지 않는다.
2. Release Branch 에서 배포 가능한 상태가 되면 (배포 준비가 완료되면),
- Master Branch에 병합한다. (이때, 병합한 커밋에 Release 버전 태그 부여)
- 배포를 준비하는 동안 Release Branch가 변경되었을 수 있으므로 배포 완료 후 Develop 브랜치에도 병합한다.
5. Hotfix Branch
출시 버전에서 발생한 버그를 수정하는 브랜치.
배포한 버전에서 긴급하게 수정을 해야할 경우, Master Branch에서 분기하는 브랜치이다.
Develop Branch에서 문제가 되는 부분을 수정하여 배포 가능한 버전을 만드는 것은 시간이 많이 소요되고 안정성을 보장하기도 어려우므로, 바로 배포가 가능한 Master Branch에서 직접 브랜치를 만들어 필요한 부분만을 수정한 후 다시 Master Branch에 병합하여 배포하는 것이다.
브랜치 관련 전체적인 흐름
브랜치가 무엇인지, 다섯 종류의 브랜치에는 무엇무엇이 있으며 각각 어떤 역할을 하는지 알아보았다.
다음 포스트에는 이 브랜치들의 활용법을 기록해보려 한다. (GitFlow, GitHubFlow 등등)
참고
https://6mini.github.io/git/2022/06/12/branch/
https://gmlwjd9405.github.io/2018/05/11/types-of-git-branch.html
https://mylko72.gitbooks.io/git/content/branch/branch_type.html
'깃, 깃허브' 카테고리의 다른 글
| Git Kraken 활용법 (0) | 2024.01.29 |
|---|---|
| Git Flow, GitHub Flow, GitLab Flow 에 관하여 (1) | 2024.01.29 |
| 깃(Git), 깃허브(GitHub)에 관하여 (0) | 2024.01.25 |