2nd/10_Wiki/Topics/Other/Pull_Request_and_Issue_Tracking.md

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, verification_status, tags, raw_sources, last_reinforced, github_commit, tech_stack

id	title	category	status	canonical_id	aliases	duplicate_of	source_trust_level	confidence_score	verification_status	tags	raw_sources	last_reinforced	github_commit	tech_stack
wiki-2026-0508-pull-request-and-issue-tracking	Pull Request and Issue Tracking	10_Wiki/Topics	verified	self	PR Workflow Code Review Issue Tracker	none	A	0.9	applied	git github workflow devops		2026-05-10	pending	language framework yaml github-gitlab

Pull Request and Issue Tracking

매 한 줄

"매 PR 의 unit of code change, 매 issue 의 unit of intent". GitHub (2008) 의 popularize, GitLab/Bitbucket/Gitea/Forgejo 의 follow. 매 2026 의 standard workflow 의 trunk-based + small PRs + automated checks + LLM-assisted review (CodeRabbit, GitHub Copilot Workspace, Claude Code).

매 핵심

매 PR Lifecycle

1. Branch — 매 feature/fix branch 의 cut from main.
2. Commit — 매 atomic change + descriptive message (Conventional Commits).
3. Open PR — 매 description (what/why/how) + linked issue.
4. CI — 매 lint, test, build, security scan.
5. Review — 매 human + LLM-assist.
6. Merge — 매 squash / rebase / merge commit.
7. Deploy — 매 main 의 push 의 trigger CD.

매 Issue Types

• Bug — 매 actual misbehavior + repro steps.
• Feature — 매 user-facing capability request.
• Task — 매 internal work (refactor, debt).
• Epic — 매 multi-PR initiative.

매 Automation Surface

• Branch protection (required reviews + checks).
• Auto-assign reviewers (CODEOWNERS).
• Auto-label / triage bots.
• Stale issue cleanup.
• Release notes (release-please).

매 응용

1. Solo project — 매 PR 의 self 의 review 의 force structure.
2. Team — 매 ownership boundary 의 CODEOWNERS.
3. OSS — 매 issue triage 의 community signal.
4. Compliance — 매 audit trail 의 SOC2/ISO 27001.

💻 패턴

PR template (.github/PULL_REQUEST_TEMPLATE.md)

## What
<one-liner>

## Why
<motivation, linked issue: #123>

## How
<technical approach summary>

## Test plan
- [ ] Unit tests pass
- [ ] Manual repro on staging
- [ ] No new warnings

## Risk
Low / Medium / High — explain.

Issue template (.github/ISSUE_TEMPLATE/bug.yml)

name: Bug report
description: File a bug
labels: [bug, triage]
body:
  - type: textarea
    id: repro
    attributes:
      label: Steps to reproduce
    validations: { required: true }
  - type: textarea
    id: expected
    attributes:
      label: Expected behavior
  - type: input
    id: version
    attributes: { label: Version }

CODEOWNERS

# .github/CODEOWNERS
*.py        @backend-team
/web/**     @frontend-team
/infra/**   @platform @sre
*.md        @docs

CI gate (GitHub Actions)

name: ci
on: [pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 22 }
      - run: npm ci
      - run: npm run lint
      - run: npm test -- --coverage
      - uses: codecov/codecov-action@v4

Auto-merge after green

name: auto-merge
on: pull_request_review
jobs:
  automerge:
    if: github.event.review.state == 'approved'
    runs-on: ubuntu-latest
    steps:
      - uses: pascalgn/automerge-action@v0.16.4
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          MERGE_METHOD: squash
          MERGE_LABELS: "automerge,!wip"

gh CLI workflow

# Create PR
git checkout -b fix/null-deref
git commit -am "fix: handle null user in checkout"
gh pr create --fill --reviewer alice,bob

# Review queue
gh pr list --search "is:open review-requested:@me"

# Triage
gh issue list --label "needs-triage" --json number,title,createdAt

매 결정 기준

상황	Approach
Small change	Squash merge
Long-lived feature	Merge commit (preserve history)
Linear history fans	Rebase + fast-forward
Many reviewers	CODEOWNERS auto-request
OSS project	Issue templates + DCO
Internal monorepo	Required checks + auto-merge

기본값: small PRs (<400 LOC) + squash merge + Conventional Commits + required CI.

🔗 Graph

• 부모: CI CD
• 응용: Code-Review · Trunk-Based-Development
• Adjacent: Conventional-Commits · CODEOWNERS

🤖 LLM 활용

언제: PR description 의 generate, review 의 first-pass (style, obvious bugs), issue triage 의 label. 언제 X: security-critical review — 매 human 의 final approve.

❌ 안티패턴

• Mega-PR (5000+ LOC): 매 review 의 useless — 매 split 의 require.
• Empty description: 매 reviewer 의 context-free.
• Force-push to shared branch: 매 review history 의 destroy — feature branch 의 only.
• Self-merge without review: 매 sole-maintainer except — 매 audit trail 의 weak.
• Issue 의 dump 의 chat: 매 GitHub issue 의 single source of truth.

🧪 검증 / 중복

• Verified (GitHub Docs 2026, Conventional Commits v1.0).
• 신뢰도 A.

🕓 Changelog

날짜	변경
2026-05-08	Phase 1
2026-05-10	Manual cleanup — PR/issue templates + CI patterns + gh CLI