////
Search
Duplicate
🛒

코딩 issue 진행 가이드

1. issue 발급

실제 branch를 생성하고 코딩을 진행한 후 PR을 진행하는 과제
예시
1. backend: login router 구현, jwt webtoken 기능 구현, 개발 환경 셋팅 2. frontend: team list component 구현, slide animation hook 구현, 개발 환경 셋팅
Plain Text
복사

2. 일반 issue 진행 가이드

2 - 1. 일반 issue 발급

반드시 월 회의 종료 시점 2시간 이내에 발급할 것!(최소 제목은 적어서 발급해 둘것)
작성법은 issue 작성 가이드 를 참고

2 - 2. 브랜치 생성 및 PR생성

브랜치는 반드시 development branch로 부터 생성한다
브랜치 네임은 <issue 타입 라벨>/<issue 번호>으로 생성
예시
1. backend에서 login 구현이 issue이고 issue타입 라벨이 feature, issue 번호가 #4인 경우 브랜치 이름: feature/#4 2. frontend에서 test환경 추가가 issue이고 issue타입 라벨이 environment이고 issue번호가 #11인 경우 브랜치 이름: environment/#11 ※ issue 번호를 사용하는 이유는 issue 제목을 한글로 작성하고 해당 issue와 연관된 브랜치가 정확하게 파악되게 하기 위함입니다 기능을 제목으로 작성하게 되면 issue이름과 브랜치 이름의 괴리가 발생할 것이라 판단하여 선정했습니다
Plain Text
복사
브랜치 생성 명령
※ 혹시 repository를 처음 받는다면! git clone development --single-branch [repo url] git checkout -b [branch name] development
Bash
복사
브랜치 push 명령
git push origin [branch name]
Bash
복사

2 - 3. Pull Request 생성

PR 생성 시점은 issue를 close하기 전 자유이지만 첫 commit 직후를 권장한다
※ issue 진행도를 PR을 통해 확인하기 위함
브랜치를 push한 후 branch로부터 development로 PR을 생성한다
PR 작성 규칙
PR의 제목은 issue와 동일하게 작성한다
PR은 최초에 issue 번호만 `resolved:#[issue번호]`로 작성한다
이후 작업을 진행하면서 생긴 문제점 새로 필요한 적용사항에 대해 기록한다
issue와 동일하게 labe, project, assgin, milstone을 등록한다 issue 작성 가이드 참고
PR생성 후 linked issue를 등록한다(그림 참고)
예시
※ 로그인 기능 구현issue고 issue번호가 #11인 경우에 PR 예시 resolved:#11 문제사항 기록 - passport연결에서 session이 기록이 잘 안되는 문제 발생 - passport.session()의 순서를 express.session() 뒤로 위치시켜 해결 ※ 해결사항 기록 - /auth/42에 대한 redirection이 정상적이지 않는 문제 발생 ※ 해결이 안되었으면 해결사항 기록X
Plain Text
복사

2 - 4. Commit

본인이 한 작업단위로 commit을 진행

2 - 5. issue 진행상황 변경(Todo 완료마다)

Todo가 완료될 때, issue의 Todo의 체크박스를 체크한다

2 - 6. issue Close

모든 Todo가 마무리되면 issue를 close 할 것(close에 따로 내용은 적지 않아도 됩니다)
해당 issue가 클로즈되면 해당 issue와 연결된 PR을 PM(seolim)이 확인하고 승인(merge) 혹은 반려(reject)한다
기본적으로는 issue monitoring을 등록(자동으로 close에 대한 기록이 오도록)해 두겠으나 확인을 바로 할 수 없는 상황인경우 오전 9시 / 12시 / 오후 5시에 일괄적으로 PM(seolim)이 확인할 예정

2 - 7. PR결과 반려 및 결제

issue가 close 된 시점에서 하루 내에 PR은 승인(merge)되거나 반려(reopen)됩니다
반려된 이유와 수정사항은 issue의 comment로 등록됩니다.
확인 후 수정 요망
반려된 issue는 reopen되고 수정 작업 후 다시 close하여 PR 결제를 받습니다

2.8 PR merge이후

merge된 후 본인의 issue 작업 branch는 삭제된다. 따라서 본인의 local에서도 삭제를 권장합니다
PR은 reopen되지 않습니다. 수정사항이 발생하면 새 issue를 발급합니다
주기단위로 진행되므로 해당 작업의 주기 파악을 정확하게 하기위해 reopen은 하지 않습니다

3. Hotfix issue 진행 가이드

hotfix의 발급은 멤버가 신청하고 PM(seolim)이 직접 발급한다.
할당 멤버는 PM(seolim)이 직접 선정하며 직접 연락으로 확인한다.
할당된 멤버는 다른 issue 작업을 중단하고 Hotfix 이슈 작업을 진행합니다
이후 진행은 일반 issue와 동일합니다