Github Flow : Git Flow의 간단한 버전
master, feature branch 밖에 없는데 안전한 이유
1. 테스크 케이스가 하나라도 틀리면 2차 배포로 넘어가지 않음 (TDD 필수)
2. 병합을 할 수 있는지 없는지는 작업자가 결정하지 않음. 합칠 때 일정 이상의 동의를 받아야 병합 가능 (룰 적용)
1. 리포지터리 생성(프로젝트 매니저)
- README 체크
2. main 브랜치에 PR 룰 걸기(프로젝트 매니저)
- Settings - Branches - Add branch protection rule 클릭
- 보안을 위해 몇 명이상 수락시 merge 할 건지 설정
3. 협력자 초대(프로젝트 매니저)
- Settings - Collaborators - Add people
- 협력자는 메일로 온 초대를 수락
4. 이슈 생성(프로젝트 매니저)
- Settings - Issues - New issue
Assignees- 누가 해당 이슈를 맡을 건지 설정할 수 있음Labels- 이슈에 대한 카테고리를 설정할 수 있음
- ex) bug - 오류, documentation - 문서, enhancement - 기능
5. 이슈 확인(협력자)
- 이슈에 대해 자신이 지정되어있으면 해당 이슈 수행. 없으면 직접 지정하고 수행
git clone <레포지토리 주소> .orgit pull origin main --rebase// git clone은 git init + git pull와 같은 말- git checkout -b enhancement/1
- 브랜치 이름 정하는 법 : 이슈의 Label/이슈의 번호 - git touch 0 (작업)
- git add . && git commit -m "작업내용"
- git pull origin main --rebase (현재 작업하고 있는 곳(로컬/enhancement/1)에 원격 저장소의 main에 있는 최신 작업본을 가져와서 병합.)
- git push origin emhancement/1 → (브랜치가 두 개 생김)
💡 push 했는데, failed to push 오류가 날 경우
push해도 이상이 없을 것 같다고 생각이 들면push origin enhancement/1 -f로 밀어붙임
6. PR 생성(협력자)
- 작업 설명
- Close #1 (PR이 잘 처리되면 자동으로 1번 이슈 close)
- PR을 올린다고 처리되는 것이 아니라 투표를 할 수 있게 된 것
7. PR로 들어온 소스코드 확인(프로젝트 매니저)
- PR을 올린 사람을 제외하여 투표 진행
- 처음에 만든 PR 룰에 대해 인원 수가 이상이면 병합할 수 있음
- File changed에서 소스코드 확인
- Review changes 클릭
Comment - 댓글
Approve - 동의
Request changes - 거절 - 동의한다면 Approve 클릭후 Squash and merge 클릭 (커밋결과가 보기 좋게 쌓임)
- 병합완료 시, 필요없는 브랜치 삭제
- 병합 후, 1번 이슈가 자동으로 닫김 (Close #1 때문에)
8. 이전 작업 내용 끝. 다시 main으로(협력자)
- git checkout main
- git pull origin main
- git branch -D enhancement/1 (로컬에 있는 필요없는 브랜치 삭제)
- git fetch --prune (서버에는 삭제됐지만 로컬에 남은 캐시 제거)
9. 4번부터 다시 반복
💡 git pull origin main과 git pull origin main --rebase의 차이점
git pull origin main : 현재 내가 작업하고 있는 로컬 브랜치에 리모트의 main 브랜치 내용을 가져와서 적용한다. (병합 방법 : merge)
git pull origin main —rebase : 현재 내가 작업하고 있는 로컬 브랜치에 리모트의 main 브랜치 내용을 가져와서 적용한다. (병합 방법 : rebase)
초심 잃지 않기