GitHub 시작 문제

  • 8분

GitHub 문제는 GitHub 리포지토리의 작업, 버그 및 기능 요청에 대한 기본 제공 추적 시스템입니다. GitHub Copilot를 사용하여 문제를 효과적으로 해결하려면 GitHub 문제를 효과적으로 사용하는 방법을 이해해야 합니다.

GitHub 문제가란?

GitHub 이슈는 팀이 작업 항목 추적, 문서 문제 및 계획 개선 사항을 추적하는 공동 작업 영역을 제공합니다. 각 문제는 추적 시스템에서 티켓으로 작동합니다. 팀 구성원에게 할당하고, 레이블로 분류하고, 코드 변경에 연결하고, 토론 및 설명서로 보강할 수 있습니다.

GitHub 문제를 팀의 지능형 to-do 목록으로 간주합니다. 각 항목은 토론, 코드 참조 및 메타데이터를 보유하여 작업이 균열을 겪지 않도록 합니다. 보안 중심 작업의 경우 GitHub 이슈는 팀이 취약성에 체계적으로 대응하는 데 도움이 되는 가시성과 추적 가능성을 제공합니다.

문제의 핵심 구성 요소

GitHub 문제의 구조를 이해하면 문제를 효과적으로 읽고 관리하고 해결하는 데 도움이 됩니다.

제목

제목은 문제의 간결하고 설명적인 요약이어야 합니다. 좋은 타이틀은 팀 구성원이 문제를 한눈에 빠르게 이해하는 데 도움이 됩니다.

효과적인 문제 제목의 예:

  • "제품 검색 엔드포인트의 SQL 삽입 취약성"
  • "사용자 암호 스토리지의 약한 암호화"
  • "파일 업로드 기능의 경로 순회 위험"

잘 작성된 타이틀은 문제 유형(보안 취약성)과 해당 위치(제품 검색 엔드포인트)를 즉시 전달합니다.

Description

설명란은 세부 정보가 있는 위치입니다. 포괄적인 문제 설명에는 다음 정보가 포함되어야 합니다.

  • 무슨 일이 일어나고 있는지 : 문제 또는 요구 사항에 대한 명확한 설명.
  • 재현 단계: 버그의 경우 문제를 트리거하는 특정 작업입니다.
  • 예상 동작: 대신 어떻게 해야 하나요?
  • 중요한 이유: 이 문제를 해결하는 것의 중요성.
  • 수락 조건: 문제가 해결되는 시기를 확인하는 방법입니다.

다음은 잘 구성된 보안 문제 설명의 예입니다.

The login authentication function stores user passwords in plaintext in the database.

**Current behavior:**
Passwords are stored directly as strings without hashing or encryption.

**Security impact:**
If the database is compromised, all user passwords are immediately exposed.

**Expected behavior:**
Passwords should be hashed using a secure algorithm (like bcrypt) with appropriate salt before storage.

**Acceptance criteria:**
- Implement bcrypt password hashing.
- Verify no plaintext passwords exist in storage.
- Update authentication to validate against hashed passwords.

잘 작성된 문제는 반쯤 해결되었습니다. 개발자가 모호한 부분 없이 문제를 바로 파악할 수 있도록 안내합니다.

코멘트

설명 섹션을 통해 팀 토론을 할 수 있습니다. 팀 구성원은 다음을 수행할 수 있습니다.

  • 명확한 질문을 하십시오.
  • 잠재적 솔루션을 제안합니다.
  • 조사 결과를 공유합니다.
  • 관련 코드 또는 문제를 참조합니다.
  • 해결 과정에서 결정된 사항을 기록하십시오.

주석은 현재 및 미래의 개발자가 솔루션의 문제와 추론을 모두 이해하는 데 도움이 되는 지식 추적을 만듭니다.

담당자

담당자는 문제를 해결할 책임이 있는 사람입니다. 명확한 소유자가 있으면 책임을 보장하고 백로그에서 문제가 발생하는 것을 방지할 수 있습니다.

모범 사례: 항상 문제에 대해 하나의 기본 소유자를 할당합니다. 담당자인 경우 해결을 위해 운전할 책임이 있습니다. 담당자가 된다는 것은 혼자 작업하는 것을 의미하지는 않으며 다른 사용자와 공동 작업할 수 있지만 결과를 소유합니다.

Labels

레이블은 문제를 분류하고 우선 순위를 지정합니다. 일반적인 레이블은 다음과 같습니다.

  • 형식 레이블: 버그, 향상된 기능, 설명서, 보안
  • 우선 순위 레이블: P0-치명적, P1-높음, P2-중간, P3-낮음.
  • 상태 레이블: 진행 중, 차단됨, 요구 사항 검토
  • 구성 요소 레이블: 백 엔드, 프런트 엔드, API, 데이터베이스.

레이블을 사용하여 목록에서 문제를 필터링하고 정렬할 수 있으므로 우선 순위가 높은 작업이나 보안 관련 작업에 더 쉽게 집중할 수 있습니다.

보안 문제의 경우 레이블은 팀이 즉각적인 주의가 필요한 취약성을 신속하게 필터링하고 우선 순위를 지정하는 데 도움이 됩니다. 보안 레이블이 P0-치명적 신호와 결합되면 문제가 긴급 조치를 필요로 한다고 표시합니다.

마일스톤

이정표는 공통 목표를 달성하기 위해 관련 문제를 그룹화합니다. 예를 들어 버전 릴리스 또는 프로젝트 단계입니다. 개별 문제 해결에는 중요하지 않지만 중요 시점은 팀이 작업을 조정하고 더 큰 목표를 향해 진행 상황을 추적하는 데 도움이 됩니다.

문제의 수명 주기 검사

문제는 만들기에서 해결로 여러 단계를 진행합니다. 이 수명 주기를 이해하면 문제를 효과적으로 관리하는 데 도움이 됩니다.

1단계: 만들기

문제는 개발자, 테스터 또는 문제 또는 개선 기회를 식별하는 사용자가 만들 수 있습니다. 보안 문제는 다음을 통해 검색할 수 있습니다.

  • 코드 검토.
  • 자동화된 보안 검사.
  • 침투 테스트.
  • 사용자 보고서.
  • 보안 감사.

문제를 만들 때 충분한 컨텍스트 및 수용 조건을 포함합니다. 이렇게 하면 문제가 해결된 것으로 간주되는 시기에 대한 명확한 기대치가 설정됩니다.

2단계: 심사

분류 과정에서 팀장 또는 지명된 사람:

  • 새 문제를 검토합니다.
  • 우선 순위 수준을 할당합니다.
  • 적절한 레이블을 추가합니다.
  • 개발자에게 문제를 할당합니다.
  • 관련 문제 또는 설명서를 연결합니다.

심각도가 높은 문제, 특히 보안 취약성은 즉시 주의하도록 플래그가 지정됩니다. 보안 문제는 반드시 평가받아야 하며, 그렇지 않으면 백로그에 남아 있어서는 안 됩니다.

3단계: 조사 및 토론

할당된 개발자가 문제를 조사합니다. 개발자는 조사 중에 다음 작업 중 하나 이상을 완료할 수 있습니다.

  • 댓글에 명확한 질문을 합니다.
  • 코드 분석의 결과를 문서화합니다.
  • 잠재적 솔루션을 제안합니다.
  • 추가 정보를 요청합니다.
  • 영향을 받는 관련 코드 영역을 식별합니다.

이 토론 단계는 수정을 구현하기 전에 모든 사람이 문제를 이해하도록 합니다.

4단계: 구현

개발자는 기능 분기를 만들고 수정 사항을 구현합니다. 구현 프로세스에는 일반적으로 다음 작업이 포함됩니다.

  • 코드 작성 또는 수정
  • 테스트 추가 또는 업데이트
  • 로컬에서 수정 사항을 확인합니다.
  • PR(끌어오기 요청) 준비하기

5단계: 커밋 및 끌어오기 요청 연결

GitHub는 커밋 메시지 또는 PR 설명에서 키워드를 사용하여 문제를 참조할 때 코드 변경 내용에 자동으로 연결합니다.

  • Fixes #123
  • Closes #123
  • Resolves #123

커밋 메시지 예제:

Fix SQL injection vulnerability in search function

Implement parameterized queries to prevent SQL injection attacks.
Add input validation for search parameters.

Fixes #42

키워드를 사용하여 문제를 참조하면 문제와 해당 솔루션 간의 추적 가능성이 생성됩니다. PR이 병합되면 GitHub는 참조된 문제를 자동으로 닫습니다. 이 자동화는 문제가 해결된 후에도 열린 상태를 유지하지 않도록 하고 문제 설명과 문제를 해결한 코드 변경 내용 간에 영구 링크를 만듭니다.

6단계: 닫기 및 확인

PR이 병합되면 문제가 자동으로 닫힙니다(제대로 참조된 경우). 테스트 결과 문제가 완전히 해결되지 않으면 더 많은 작업을 위해 다시 열 수 있습니다.

모범 사례: 닫은 후 원래 문제 설명의 수락 조건이 충족되는지 확인합니다. 보안 문제의 경우 보안 테스트를 통해 추가 확인을 고려하세요.

Visual Studio Code에서 GitHub 문제 관리

Visual Studio Code는 GitHub 끌어오기 요청 확장을 통해 GitHub 문제와 직접 통합됩니다. 이 통합을 통해 다음을 수행할 수 있습니다.

  • 편집기를 종료하지 않고 할당된 문제를 봅니다.
  • Visual Studio Code 내에서 새 문제를 만듭니다.
  • 작업하면서 코드 변경 내용을 문제에 연결합니다.
  • 코드와 함께 문제 세부 정보를 검토합니다.

Visual Studio Code에서 GitHub 문제에 액세스하려면 다음을 수행합니다.

  1. "GitHub 끌어오기 요청 및 문제" 확장을 설치합니다.
  2. GitHub 계정으로 로그인합니다.
  3. GitHub 패널에서 문제를 봅니다.
  4. 담당자, 레이블 또는 중요 시점별로 필터링합니다.

이 긴밀한 통합은 코딩하는 동안 문제 컨텍스트를 표시하여 워크플로를 간소화합니다.

효과적인 문제 관리가 중요한 이유

명확한 이슈 추적은 특히 보안에서 중요한 문제가 간과되는 것을 방지합니다. 이러한 실제 시나리오를 고려합니다.

  • 사소한 문제는 주요 인시던트가 됩니다. 공격자가 먼저 발견하면 백로그의 "사소한" 보안 문제가 심각한 인시던트가 될 수 있습니다. GitHub 문제의 보안 문제는 표시되고 추적할 수 있습니다. 해당 가시성을 책임 도구로 사용합니다.

  • 제도적 지식 손실: 문제가 제대로 문서화되지 않거나 추적 시스템 외부에서 논의가 발생하면 귀중한 컨텍스트가 사라집니다. 향후 개발자(6개월 내 포함)는 특정 결정이 내려진 이유를 이해하지 못할 수 있습니다.

  • 지연된 응답: 명확한 우선 순위 레이블 및 담당자가 없으면 중요한 보안 취약성이 적시에 주의를 기울이지 않을 수 있습니다.

문제 기반 개발 수용: 문제를 식별하고, 수정하고, 수정을 확인하고, 문제를 닫고, 계속 진행합니다. 이 체계적인 접근 방식은 완전성을 보장하고 코드베이스에 대한 신뢰를 구축합니다.

요약

GitHub 이슈는 소프트웨어 개발에서 체계적인 문제 해결을 위한 토대를 제공합니다. 문제를 효율적으로 해결하려면 문제를 효과적으로 읽고 해석하고 관리하는 방법을 이해해야 합니다.