🔥 Branch 전략 🔥

Git Flow 브랜치 전략 참고

• main : 제품으로 출시될 수 있는 배포 브랜치
• be/* : backend 전용 작업 branch
• an/* : android 전용 작업 branch
• an/develop, be/develop: 다음 출시 버전을 개발하는 브랜치
• an/feat/*, be/feat/* : 기능 개발하는 브랜치 (e. an/feat/pokedex)
• an/release : 이번 출시 버전을 준비하는 브랜치 (QA, BugFix)
• an/hotfix: 출시 버전에서 발생한 버그를 수정 하는 브랜치

• */develop, */feat/작업명, hotfix, release (브랜치 삭제, 생성 매번 해줘야함)
• hotfix, release, main 은 Android, Backend 가 함께 사용하는 공용 브랜치이다.

💥 AN 깃 브랜치 컨벤션

1. 작업 브랜치 네이밍 컨벤션

branch 는 항상 an 을 root로 삼는다.

an{태그}/화면_작업명

ex) an/feat/type_ui

2. 깃허브 브랜치 전략

🔥 main , an/develop, an/feat, an/refactor, an/release, an/hotfix 이 존재한다.

an/develop 에서 작업 브랜치를 생성한다.

3. 브랜치 작업 방식

branch 를 생성하여 작업하는 경우 이와 같은 과정을 따른다.

1. branch 를 생성하기 전 git pull 을 통해 develop을 업데이트 한다.
2. 브랜치를 네이밍에 맞게 생성한다.
3. git fetch 를 통하여 발생하는 conflict 를 확인한다.
4. git pull --rebase [원격 저장소] [브랜치] 명령어를 통해 리베이스 하여 해결한다.
5. 변경사항들을 commit 후에 push 한다.
6. squash merge 후 머지된 브랜치를 delete 한다.

💥 BE 깃 브랜치 컨벤션

1. 작업 브랜치 네이밍 컨벤션

반드시 be/** 방식으로 사용한다.

be/{태그}/#{이슈번호}-{CRUD}-{도메인이름}-api

ex) be/feat/#123-post-pokemon-api , be/fix/#124-post-pokemon-api

2. 깃허브 브랜치 전략

🔥 main , be-develop, be-feat/ 이 존재한다.

be-develop 에서 작업 브랜치를 생성한다.

3. 브랜치 작업 방식

branch 를 생성하여 작업하는 경우 이와 같은 과정을 따른다.

1. branch 를 생성하기 전 git pull 을 통해 develop을 업데이트 한다.
2. 브랜치를 네이밍에 맞게 생성한다.
3. git fetch 를 통하여 발생하는 conflict 를 확인한다.
4. git pull --rebase [원격 저장소] [브랜치] 명령어를 통해 리베이스 하여 해결한다.
5. 변경사항들을 commit 후에 push 한다.
6. merge 후 머지된 브랜치를 delete 한다.

🎫 미션

1. hotfix 브랜치를 main에서 딴다.
2. feat 브랜치에 역할을 커밋/푸쉬한다.
3. hotfix브랜치에서 프로젝트소개 브랜치를 따고, main과 dev브랜치에 머지를 시킨다.
4. feat브랜치에서 담당코치를 작성하고 dev → relaese → main 순으로 머지한다.
5. 역할을 dev → release(qa가 있다면 qa를 진행한다) → main순으로 머지한다.