모범 사례
사람 검토자가 있는 팀
사람이 모든 풀 리퀘스트를 검토하면 그 시간의 상당 부분이 세부 사항과 엣지 케이스에 쓰입니다. HeyDeer가 모든 풀 리퀘스트에서 이를 맡으면 검토자는 설계와 제품 결정에 집중할 수 있습니다.
HeyDeer가 맡는 일
- 세부 사항과 엣지 케이스. HeyDeer는 모든 풀 리퀘스트에서 오류 처리, 경계값, 동시성, 그리고 변경으로 인해 깨지는 호출부를 확인합니다.
- 검토자의 부담 감소. 검토자가 실수를 찾으려고 모든 줄을 따라갈 필요가 없으므로, 검토자만 내릴 수 있는 결정에 시간과 주의를 쓸 수 있습니다.
- 세부 사항까지 정확하게. 내부 풀 리퀘스트 1,000개에서 HeyDeer는 세부적인 코드의 올바름을 사람 검토자보다 더 정확하게 검토했습니다.
권장 구성
풀 리퀘스트 생성
HeyDeer가 세부 사항 검토
작성자가 발견 사항 수정
검토자가 설계 확인 후 병합
- 푸시할 때마다 검토하세요. 워크스페이스 설정 → 검토 규칙에서 “검토 일정”을 “푸시할 때마다”로 설정하세요. 자동 검토를 참고하세요.
- 문제가 있으면 검사가 실패하도록 하세요. “결과 게시” 아래에서 “문제가 발견되면 검사를 실패로 표시”를 켜세요. HeyDeer Review 검사를 참고하세요.
- GitHub에서 검사를 필수로 지정하세요. main 브랜치 규칙에서 Require status checks to pass before merging 옵션을 켜고 HeyDeer Review를 추가하세요. 그러면 풀 리퀘스트는 발견 사항을 수정하거나 처리하지 않기로 결정한 후에만 병합됩니다.
- 사람의 검토는 HeyDeer의 결과에서 시작하세요. 검토자에게 검사를 통과한 풀 리퀘스트를 열어 보도록 하고, 설계, 제품 동작, 그리고 HeyDeer가 사람의 판단이 필요하다고 표시한 부분에 시간을 쓰도록 요청하세요.
일부 검사가 성공하지 못함
HeyDeer Review — 검토에서 처리해야 할 문제를 발견함필수
CI / test — 성공필수
병합이 차단됨
선택 사항: 일상적인 변경 자동 승인하기
자동 승인을 켜고 “사람의 승인이 필요한 변경”은 “중대한 아키텍처 및 핵심 동작 변경”으로 그대로 두세요. 그러면 HeyDeer는 남은 문제가 없는 일상적인 풀 리퀘스트를 승인하고, 중대한 변경은 사람이 내려야 할 결정을 명시해 사람에게 맡깁니다.
브랜치 규칙에서 필수 승인 수가 1이면, 일상적인 풀 리퀘스트는 검토자를 기다리지 않고 병합할 수 있습니다. 모든 승인이 최신 코드를 기준으로 하도록 Dismiss stale pull request approvals when new commits are pushed 옵션을 켜세요.
팀의 기준을 검사로 작성하기
검토자가 댓글에서 반복해서 지적하는 규칙은 검사로 만드세요. 규칙마다 .agents/checks/에 Markdown 파일을 추가하면, HeyDeer가 일치하는 파일을 변경하는 모든 풀 리퀘스트에 그 규칙을 적용합니다. 저장소 검사를 참고하세요.
.agents/checks/migrations.md
---
files: "migrations/**/*.sql"
---
The previous release keeps running while a migration
deploys. Report a migration that:
- drops or renames a table or column that code on the
base branch still uses;
- adds a NOT NULL column without a default;
- creates an index on an existing table without
CONCURRENTLY.