PR은 코드만 보내는 버튼이 아니다

Pull Request는 "이 브랜치의 변경을 합쳐달라"는 요청입니다. 동시에 리뷰어가 가장 먼저 읽는 문서이기도 합니다.

어제 만든 PR의 정체를 다시 말하면 이렇습니다.

origin의 브랜치를 upstream에 합쳐달라고 제안한 문서

리뷰어가 읽는 순서로 쓰기

처음에는 아래 세 가지만 적어도 충분합니다.

제목: feat: 검색 자동완성 추가

## 무엇을 / 왜
검색 입력 시 자동완성 목록을 표시합니다. Fixes #12

## 확인 방법
"git" 입력 → 하단에 제안 5개 표시

제목은 conventional commits 형식을 그대로 쓰면 좋습니다. 본문은 "무엇을 바꿨는지", "왜 바꿨는지", "어떻게 확인했는지"를 리뷰어가 바로 볼 수 있게 씁니다.

좋은 PR 설명의 기준

• 제목만 봐도 변경 성격이 보인다.
• 이슈 번호가 연결되어 있다.
• 실행하거나 확인하는 방법이 있다.
• 리뷰어가 코드를 열기 전에 맥락을 알 수 있다.

오늘은 만들지 않고 이해한다

2회차에서는 새 PR을 실제로 만들지 않습니다. 어제 이미 PR 버튼을 눌러봤고, 오늘은 그 흐름의 의미를 이해하는 날입니다.

실제 오픈소스 기여와 PR 실행은 4회차에서 다시 다룹니다.

---

다음은 저장소에 들어온 사람이 처음 읽는 문서, README를 정리합니다.