브랜치 전략에 대해 얘기하기 전에
• 브랜치란?
독립적으로 어떤 작업을 진행하기 위한 개념
개발자들이 동시에 다른 작업을 할 수 있게 만들어 주는 기능
각각의 브랜치는 다른 브랜치의 영향을 받지 않음
하늘색 : main(master) 브랜치
보라색, 초록색 : 분기된 브랜치
main 브랜치의 코드를 통째로 복사해서 나의 브랜치로 이동 후
나의 브랜치에서 개발을 진행하는 것이 일반적임
• Git Workflow가 뭔데?
Git은 브랜치로 작업을 관리하는데
팀에서 브랜치를 어떻게 사용할 지에 대한 규칙을 Workflow 라고 함
• Git Flow
총 5가지의 브랜치를 사용
master, develop, feature, release, hotfix
- master 브랜치
제품을 배포하는 브랜치
- develop 브랜치
master 브랜치에서 나온 브랜치
개발자들이 이 브랜치를 기준으로 각자 작업한 기능들을 합침(merge)
- feature 브랜치
단위 기능을 개발하는 브랜치
기능 개발이 완료되면 develop 브랜치에 합침
- release 브랜치
develop 브랜치에서 나온 브랜치
배포를 위해 master 브랜치로 보내기전에 먼저 품질검사를 하기 위한 브랜치
(테스트용?)
- hotfixt 브랜치
master 브랜치로 배포했지만 버그가 생겼을 때 긴급 수정하는 브랜치
• GitHub Flow
이름 그대로 GitHub 환경에서 사용하기 적합한 브랜치 전략
- master 브랜치
master 브랜치는 항상 최신 상태, stable(모든 커밋은 언제 배포하든 문제 X)한 상태
모든 커밋은 빌드가 되고, 테스트를 통과해야 함
언제든 브랜치를 새로 만들어도 문제가 없어야 함
- 브랜치 생성
브랜치는 항상 master 브랜치에서 만들고,
브랜치 이름은 자세하게 작성(어떤 작업을 하는 지)
- Add Commits
커밋 메시지는 명확하게 작성
push를 수시로 해서 다른 사람들도 확인할 수 있도록 해야 함
-> 구성원 모두가 계속해서 소통하도록 해줌
- Pull Request(PR)
아이디어 공유, 토론, 피드백 등이 필요하면 아무때나 개설 가능
PR을 이용해 자신의 코드를 리뷰 받을 수 있음
- 테스트
테스트 해본 후 문제가 발생한다면
master 브랜치의 내용을 다시 배포하여 초기화시킴
- Merge
테스트에서 문제가 발생되지 않는다면 master 브랜치에 푸시 -> merge
master로 merge되고 push 되었을 때는, 즉시 배포되어야 한다.
=> GitHub-flow의 핵심
'Git' 카테고리의 다른 글
| Squash Merge.. (0) | 2024.07.15 |
|---|---|
| Git/GitHub (0) | 2023.04.28 |