Git-flow 브랜치 종류 5가지
main : 제품으로 출시(배포)될 수 있는 브랜치
develop : 다음 출시 버전을 개발하는 브랜치
feature : 기능을 개발하는 브랜치
release : 이번 출시 버전을 준비하는 브랜치
hotfix : 출시 버전에서 발생한 버그를 수정하는 브랜치
develop과main은 중심이 되는 브랜치
git flow에서 두 브랜치는 반드시 존재해야 한다.
(develop 브랜치는 main에서부터 시작된 브랜치)
💡 초기 세팅
👤 한 명만 작업해도 된다!
- 팀 레파지토리 setting에 들어간다.
- Collaborators 에서 팀원들에게 권한을 준다. 깃허브에 등록한 이메일에 가서 권한 수락 필요
3. Branches 에서 default branch develop으로 바꾼다. (main이 삭제되고 develop으로 대체되어버림)
3. Code 👉 1 branch 👉 New branch 👉 develop 생성 👉 Default branch develop으로 바꾸기
develop 브랜치를 Default로 설정하는 이유?
평소에는 develop 브랜치를 기반으로 개발을 진행하기 때문!
각자feature 브랜치에서 작업하고develop 브랜치에 머지하는 방식
👥 나머지 팀원들은?
HTTPS 복사해서 로컬 폴더에 클론
git clone (레파지토리의 HTTPS 주소) . (끝에 점 찍으면 하위디렉토리를 생성하지 않는다)
branch 확인하기
git branch🤔💦
git branch에서 develop 밖에 확인이 안돼서
git switch main으로 브랜치 이동을 한번 해주고
git branch로 확인하면 develop, main 둘 다 확인했음
🔥 작업 시작
1. New Issue
Assignees, labels 선택
이슈 제목 ex) [Feat] 로그인 기능 구현
팀원들이 이해하기 쉽도록 어떤 작업을 할 것인지 자세하게 작성하자
2. 작업 Start
develop 브랜치로 이동
git switch developpull origin은 처음에 한 번만
이후에는 develop으로 이동해서 git pull
git pull origin develop본인이 작업할 브랜치 생성 후 이동
❗️develop에서 작업하지 않도록 주의
git branch 브랜치명 //생성
git branch //확인
git switch 브랜치명 //이동브랜치명 ex)
feature/이슈번호
feat/이슈번호
등등등3. 작업 End
👉 commit (본인 브랜치에서)
git commit -m '#이슈번호 - 키워드: 상세 설명'👉 push
git push origin 브랜치명4. PR
Reviewers(팀원들), Assignees(본인), Labels 체크하기
머지 되면 이슈가 close 된다는 것을 알려주기 위해서 close #이슈번호 넣기 (#을 치면 저렇게 알려준다. 이슈탭에서도 확인 가능)
👉 Create pull request
5. Code Review
이제 팀원들은 Files changed에서 작성된 코드를 확인한다.
코드 왼쪽에 ➕ 버튼 클릭해서 리뷰를 남길 수 있다.
Review Changes에서도 코멘트 남길 수 있음!
6. Merge
팀원들 모두(혹은 몇 명 이상) 확인하면 👉 Merge pull request
Merge 후에 👉 Delete branch (이제 이 브랜치는 필요 없음)
✔️ Issues탭에서 closed 됐는지 확인
✔️ develop 브랜치에 작업한 내용 합쳐졌는지 확인
로컬에는 여전히 나의 브랜치가 존재하므로 삭제한다.
❗️ develop 브랜치에서 삭제
git branch -D 브랜치명7. 다시 작업 start
❗️ 시작할 때 develop 브랜치에서 git pull 잊지 말기
