| 항목 | 값 | 비고 |
|---|---|---|
| 분류 | 팀전 | |
| 리뷰어 | 팀원 모두 | PR 올린 당사자 제외 |
| 준비물(스탭) | * 노트북 * 팀 구성 * GIT 기능 별 구성파일 만들기 후 n개의 feature 브랜치 생성해두기 * main 브랜치 보호 걸어놓기 |
|
| 준비물(참가자) | * 노트북 * GitHub 계정 |
Merge 정책 미리 논의해두기 |
| 미리 구성할 파일 | git_reset.md, git_switch.md, git_blame.md, git_merge.md |
- GIT 기본 사용 방법에 익숙해지기
- 왜 Branch를 사용하는지 이해하기
- 왜 Pull Request(Merge Request)를 사용하는지 이해하기(약어: PR/MR)
- Conflict에 당황하지 않기
- 실무 협업에 좀 더 가깝게 이해하기
- 참가자는 이 Repo를 Clone 합니다.
- 참가자는 받아진 저장소에 들어가서 미리 스탭이 만들어놓은 팀별 브랜치로 이동합니다.
- 참가자는 팀에서 정한 역할대로 한개의 파일을 맡아 최대 10분간 조사하여 정리합니다.
- 참가자는 자신이 잘 정리했다고 생각될 때 Commit 후 Push 합니다.
- 참가자는 이제 GitHub에 접속하여 자신이 올린 작업에 PR을 생성합니다.
- 리뷰어는 PR 페이지 올라온 내용을 확인 의견을 작성하거나 해당 PR이 잘 됐다고 판단되면 Approve 및 Merge를 진행합니다.
- 스탭은 미리 내용을 입력해놓은 후 먼저 main에 PR 후 머지합니다.
- 스탭은 30분에 한번씩 한팀씩 순차적으로 main에 머지하도록 유도합니다.
- 참가자는 스탭이 main에 머지하라고 요청받으면 PR을 생성합니다. 만약 Conflict이 발생한다면 팀에서 해결합니다.
- 4번에서 참가자가 main 브랜치에 바로 커밋했을 경우 빨간 메시지를 볼 수 있습니다(Branch를 왜 만드는지 이해).
- 5번에서 모든 참가자는 PR하는 방법을 익힐 수 있습니다(왜 Pull Request를 사용하는지 이해)
- 5번에서 일부 참가자는 Merge 버튼이 회색이면서 파일이 충돌난다는 메시지를 볼 수 있습니다(Conflict에 당황하지 않기).
- 6번에서 모든 참가자는 PR에 리뷰하는 방법을 익힐 수 있습니다.
- 9번에서 실무 협업에 좀 더 가깝게 이해할 수 있습니다.