링크
[Git&GitHub]
1. 브랜치 전략
1.
develop에 페이지 별 브랜치 생성
2.
각자 작업 브랜치 생성
3.
페이지 브랜치로 PR 및 Merge 진행
브랜치 작명 예시: feat/login (로그인 페이지 브랜치)
login/기능 (작업하고 PR을 페이지 브랜치로 날릴 브랜치)
2. Issue
2.1 Today’s Issue
•
Issue 제목: [카테고리] 할 내용
(카테고리: feat, design, refactor)
예시
•
발행인: 본인
•
작성 내용:
◦
Description
◦
오늘 할 일 (To-do List)
예시
•
사이드바
Assignees | 본인 |
Label | 작업 페이지, 구현할 기능 |
Projects | Spport |
Milestone | 작업 페이지 |
•
진행순서
1.
체크리스트 하나가 완료되면 커밋
(커밋 메시지는 체크리스트와 동일하게 작성)
2.
할일을 모두 끝낸 후 중점사항 작성
3.
issue close
체크리스트를 다 하지 못한채 이슈를 닫아야한다면, 진행중인 리스트를 없애고 이슈를 닫은 후, 그 리스트는 다음 날로 옮겨서 진행 (진행중이었던 리스트 커밋X)
예시
2.2 버그 발견 Issue
•
Issue 제목: [Bug #이슈번호] 버그 설명
•
발행인: 버그를 발견한 사람(작업한 본인 포함)
•
작성 내용:
◦
버그 내용: 발견한 버그에 대해 기술
◦
재현 과정: 버그를 발견하기 까지 과정을 작성
▪
1. 어떤 페이지에서?
▪
2. 어떤 기능이?
ex
◦
예상 원인: 버그가 야기된 추측되는 근거 작성
◦
스크린샷
•
사이드바
Assignees | 버그를 발견한 사람 |
Label | bug, 해당 페이지, 기능 |
Projects | Spport |
Milestone | 작업 페이지 |
예시
2.3 도움 요청 Issue
•
Issue 제목: [help #관련이슈번호] 도움요청제목
•
발행인: 도움요청인
•
작성 내용: 어떤 문제 상황인지 작성
•
사이드바
Assignees | 도움이 필요한 사람 |
Label | help, 해당 페이지, 기능 |
Projects | Spport |
Milestone | 작업 페이지 |
예시
Issue template 만드는 법
3. Label
•
페이지, 기능
ex) bug, design, feat, help
역할분담
4. Milestone
•
프로젝트 진행과정에서 필요한 주요 목표 과제
•
관련 이슈들을 그룹핑, Progress bar를 통해 전체적인 진행현황을 추적 가능
•
제작해야하는 페이지, 해당 과정
ex) Login page, HTML 마크업
생성 방법
5. Project
6. PR 발행
•
PR 발행은, 각자 맡은 역할을 위해 브랜치를 생성하고, "첫 커밋"시에 feat/페이지 브랜치로 PR을 날린다. (매우 중요)
•
PR을 날린후, 커밋은 첫 커밋시 날렸던 PR에 쌓이게 되며, feat/페이지 브랜치에 머지시에, 커밋내역이 이동한다.
•
PR 내용: 체크리스트에는 본인이 진행한 역할에 대해 작성하고 체크한다, 기대 사항은 본인이 맡은 역할에서 어떤 걸 얻었는지 작성, 전달 사항은 해당 페이지 다른 작업시에 주의해야할 점을 작성한다. 스크린샷은 완료된 작업을 캡쳐하여 작성한다.
Questions
1.
저희가 위 방식처럼 브랜치 전략을 사용하려고 하는데 그럼 upstream repo에서 develop 브랜치만 만들고 그것을 저희가 각자의 repo에 pull해와서 feat/login 브랜치를 따로 만들어서 또 보라색처럼 브랜치를 만들고 전부 feat/login에 머지하고 feat/login이 전부 끝났을 시에 upstream repo에 PR하게 되는 건가요?
ex) login/style 브랜치에서 첫 커밋 후 푸쉬하고, feat/login 브랜치로 PR을 날린다.
