아직 확정되지 않은 사항입니다 (by 성인)

의견

• 가장 많은 에너지를 쏟아야하는 규칙이라는 생각입니다.
• 과할정도로 많이 작성하는것이 좋다(평범한 의미의 PR이 아닌 문서화의 의미를 포함하기를 원합니다)
• 하지만 PR의 내용인 code는 적으면 적을 수록 좋습니다
• 서로 다른 포지션 (FE <=> BE)도 이해할 수 있도록 작성할것
• 테스크를 수행하던 모든 과정중 “생각의 흐름”을 담으려고 노력하면 좋을것 같습니다.
• 정제해서 작성하기 위해 에너지를 소모하기보다는 오히려 많은양을 작성해서 남기는것에 집중하기를 원합니다.
• 각 PR은 CI/CD 테스팅은 필수
• 공통포지션의 모든 구성원이 approve 해야만 merge 합니다.
• PR 불가능한 시간을 약속합니다(예를 들어 새벽이라던가…)
• PR의 내용이 상세할 수록 blog를 작성하거나 추후 포트폴리오 작성에 큰 도움이 될 것 입니다. 단순히 프로젝트 수행 과정이 아닌 추후 포트폴리오 작성을 겸하고 있다고 생각하면 좋을 것 같습니다.

template 예시

# Why
// 해당 테스크를 수행해야만 했던 배경에 대해 작성합니다.
# How
// 해당 테스크를 수행하기 위한 과정과 흐름에 대해 집중해서 작성합니다.
# Result
// 해당 테스크를 통한 결과에 대해 담백하게 작성합니다.
# Prize
// 해당 테스크를 통해서 어떤 기술적 성취가 있었는지 작성합니다.(수치적인 개선점 등)
# Reference
// 해당 테스크를 수행하며 참고한 Link를 모두 작성합니다.
# Link
// jira 혹은 figma 링크를 작성합니다.

Reference

좋은 Pull Request를 만드는 방법과 PR Template 구성

[Github] ⚡️더 자주 Merge 되는 PR 만들기 - 빠른 협업하기(feat. 라인, 배민, 뱅크샐러드)