728x90
▶ Branch 전략이란?
- 여러명의 개발자가 1개의 저장소를 사용하는 환경에서 효과적으로 사용하기 위해 나온 개념.
- 거의 모든 기업들이 자신들의 상황에 맞는 전략을 사용하고 있음.
- 대표적인 전략
- GitHub flow
- Git flow
- GitLab flow
- 등등....
▶브랜치 전략이 왜 필요할까?
git을 개인프로젝트를 저장하는 공간으로 혼자 사용한다면 브랜치 전략은 필요하지 않을 수도 있다.
하지만 다수의 사람들이 함께 진행하는 프로젝트에서는
정해진 브랜치 규칙이 없이 다수의 사람들이 무분별하게 자신의 브랜치를 만들고 개발하는 중에 새롭게 분기하고 다 사용한 브랜치를 삭제하지 않을 경우 많은 불편함과 문제점이 발생한다.
그래서 브랜치 전략이 필요하다.
▶ GitHub flow란?
- GitHub flow은 GitHub에서 만든 단순한 구조의 브랜치 전력이다.
- Master브랜치를 중심으로 운영되며, 기능 개발 버그 수정들의 작업용 브랜치를 구분하지 않는 단순한 구조이다.
- 지속적으로 테스트 및 배포를 하는 팀의 경우 GitHub flow를 사용하는 것이 좋다.
▷ 1. 브랜치 생성
- Master로부터 기능추가, 버그 수정 작업을 위한 새로운 브랜치를 생성한다.
- 이때 commit 메시지와 브랜치 이름은 정확하고 간결하게 작성해야한다.
- 기능추가, 버그 수정 작업을 하는 모든 브랜치는 master 브랜치로부터 분기된다.
▷ 2. 기능 개발, 버그 수정
- 브랜치를 열었으면 하고자 하는 작업을 하며 기능별로 commit을 한다.
- commit은 서버의 동일한 브랜치에 push해줘야한다.
▷ 3. Pull Request 생성
- 기능 또는 오류 수정이 완료되었으면 PR을 보낸다.
#Pull Request란?
- Pull Request는 사용자가 원격 저장소에 Push하여 새로운 사항이 적용됬을 경우, 다른 사용자에게 푸쉬된 상황을 알리는 것을 말한다. 이를 줄여서 PR이라고도 한다.
- pull request를 보내 놓으면 여러 동료들에게 리뷰를 받을 수 있고, 내가 올린 코드에 동료가 병합하여 진행할 수도 있다.
PR까지 전체적인 과정
저장소를 clone → 브랜치 생성 및 이동 → 소스코드 작성 및 변경 → 변경한 내용을 git add로 스테이징 영역에 저장 → git commit으로 변경 사항을 저장 → git push로 원격 저장소에 소스코드를 올림 → Pull Request를 전송
▷ 4. 리뷰와 논의
- PR을 통해 팀원과 작성한 코드에 대한 리뷰와 논의를 한다.
▷ 5. 공개 및 테스트
- GitHub에서는 Master에 merge하기 전에 브랜치내에서 코드를 배포할 수 있는 장점이 있다.
- 이러한 기능을 통해 merge 이전에 먼저 배포를 하여 사용을 해보며 해당 브랜치에 문제가 발생할 시에는 안정적인 기존의 master브랜치를 다시 배포하고 브랜치 코드는 다시 수정한 후 다시 배포할 수 있다.
▷ 6. 합치기(Merge)
- Branch의 검증이 완료되면 메인 브랜치에 합친다.
▶ Git flow란?
- Git flow는 Vincent Driessen이 2010년에 제안한 Barnch Model을 기반으로 만들어 졌으며 현재는 많은 기업에서 표준으로 사용하는 브랜치 전략이다.
- 배포 주기가 길고 팀의 여력이 있는 경우 적합한 전략이다.
- GitHub flow와는 다르게 크게 5개의 브랜치를 운영하며 관리한다.
- 메인 브랜치 : maseter, develop
- 보조 브랜치 : feature release, hotfix
- branch를 merge할 때 항상 -no-ff 옵션을 붙여 branch에 대한 기록이 사라지는 것을 방지하는 것을 원칙으로 한다.
- --no-f 이란?
- 브랜치 전략에서 merge를 할 때 사용하는 것을 권장한다.
- Fast-forward관계에 있어도 Merge commit을 생성하여 해당 브랜치가 존재하였다는 정보를 남길 수 있다.
- commit기록을 되돌리기 편해진다.
- --no-f 이란?
- --no-ff을 사용하지 않으면?
- 브랜치의 존재 여부를 몰라 어떤 commit부터 해당 기능을 구현했는지 확인하기 어렵다.
▶ 메인 브랜치들의 특징
- Master와 Develop 브랜치가 있다.
- 이 두개의 브랜치는 항상 남아있는다.
- Master브랜치는 제품으로 배포할 수 있는 브랜치이다.
- Develop브랜치는 개발자들이 개발을 하는 브랜치이다.
▷ Master브랜치
- 기준이 되는 브랜치로 제품을 배포하는 브랜치
- 현재 필드위에 나가있는 프로덕션 코드들이 위치함.
▷ Develop브랜치
- 개발 브랜치로 개발자들이 이 브랜치를 기준으로 각자 작업한 기능들을 Merge
- Develop브랜치는 처음에 Master로부터 분기하는것으로 시작하며 다음 버전이 구현이 완료되어 배포를 하고 싶을 때 Master로 다시 합치는 방식으로 운영된다.
▶ 보조 브랜치의 특징
- feature, release, hotfix 브랜치가 있다.
- 보조 브랜치들은 메인 브랜치와 다르게 사용을 마치면 브랜치를 삭제한다.
▷ Feature 브랜치
- 단위 기능을 개발하는 브랜치로 기능 개발이 완료되면 develop 브랜치에 Merge
- 브랜치가 분기되는 곳 : develop
- 브랜치가 merge되는 곳 : develop
- feature 브랜치는 하나의 새로운 기능을 만들 때 생성한다.
- develop에 merge후에는 삭제한다.
- merge 할 때는 —no-ff를 사용하여 기록을 그룹화한다
▷ Release 브랜치
- 배포를 위해 master 브랜치로 보내기 전에 먼저 QA(품질검사)를 하기위한 브랜치
- 브랜치가 분기되는 곳 : develop
- 브랜치가 머지 되는 곳 : develop& master
- 버그 수정 및 버전 번호, 빌드 날짜와 같은 메타 데이터를 준비하며 기능 개발은 금지된다.
- merge할 때는 —no-ff를 사용하여 기록을 그룹화한다.
- master로 merge후에는 tag명령을 통해 버전을 명시한다.
▷ Hotfix 브랜치
- master 브랜치로 배포를 했는데 버그가 생겼을 떄 긴급 수정하는 브랜치
- 브랜치가 분기되는 곳 : master
- 브랜치가 머지 되는 곳 : develop & master
- Production에 버그가 발생하면 빠른 수정을 위해 생성하는 브랜치이다.
- Production코드를 수정하는 중에서 develop에서는 계속 개발을 할 수 있다는 장점이 있다.
- master로 merge 후에는 tag명령을 통해 이전 버전보다 높은 버전을 명시한다.
- ex) 1.2 → 1.2.1
▷ 전체적인 흐름 요약 (ios 업데이트 예시)
▶ Fork와 Pull Request
- 규모가 있는 개발을 할 경우 브랜치 보다는 Fork와 Pull requests를 활용하여 구현을 한다.
- Fork는 브랜치와 비슷하지만 프로젝트를 통째로 외부로 복제해서 개발을 하는 방식이다.
- 개발을 해서 브랜치처럼 Merge를 바로 하는 것이 아니라 Pull requests로 원 프로젝트 관리자에서 머지 요청을 보내면 원 프로젝트 관리자가 Pull requests된 코드를 보고 적절하다 싶으면 그때 그 기능을 붙히는 식으로 개발을 진행한다.
▣Reference
https://youtu.be/wtsr5keXUyE?si=NEBTehlm2UTQZoRI
https://velog.io/@kw2577/Git-branch-%EC%A0%84%EB%9E%B5
728x90
'Back-end > Git & GitHub' 카테고리의 다른 글
| [Git&GitHub] ! [rejected] main -> main (non-fast-forward) 해결 방법 (2) | 2024.03.26 |
|---|---|
| [GitHub] GitHub Action이란? (0) | 2024.03.09 |
| [GitHub]원격의 브랜치 다루기 (0) | 2024.02.25 |
| [GitHub]push, pull, pull 할 것이 있을 때 push를 하면? (1) | 2024.02.25 |
| [GitHub]GitHub 원격 저장소 사용하기 (0) | 2024.02.20 |
