깃 브랜치 전략

$Git$ $Flow$

• hotfix를 main에 병합 후 main을 배포 | | hotfix | 배포 중인 앱에 버그 발생 시 긴급하게 해결하는 곳 | - main에서 분기 후 오류 수정
• 수정 완료 후 main과 develop에 병합 | | release | 작업물을 배포하기 위해 코드를 최종 점검하는 곳 (버전 관리) | - develop에서 분기 후 코드 정리 (오류 수정 등)
• 정리 완료 후 dev에 병합
• release 생성으로 버전 관리 | | develop | 현재 개발중인 모든 코드가 모이는 곳 | - 작업이 완료 된 feature 브랜치를 develop에 병합 | | feature | 병렬 작업을 위해 기능 별로 나누어 개발하는 곳 | - 각 개발자는 맡은 기능에 따른 feature 브랜치 생성
• 이곳에서 개발 후 develop에 병합 요청 (PR) |

<aside> 💡

알쓸잡: 왜 master는 main이 되었을까?

예전에는 기본 브랜치가 master라는 이름이었는데요, 지금은 main으로 바뀌었습니다

master는 흑인 노예제 시기 주인님을 칭하는 단어였습니다

잔재를 남기지 않겠다는 의지가 반영된 것입니다

</aside>

Release 전략

Semantic versioning을 따릅니다

온점을 기준으로 세 구간으로 구성됩니다

• major : 큰 변화 (호환되는 API가 없을 때)
• minor : 단순 기능 추가, 리팩토링 등
• patch : 버그 수정

major는 쓸 일 없을 거예요!

Jira 활용