mason
mason-log.

mason

mason.

안녕하세요. mason 입니다.

version-control

GitHub.

원격 저장소, Pull Request, 코드 리뷰, Issue와 협업 흐름

GitHub는 Git 저장소를 호스팅하고 코드 리뷰, 이슈 관리, 자동화 같은 협업 기능을 제공하는 서비스다. Git이 로컬 변경 이력을 관리한다면 GitHub는 그 이력을 팀과 공유하는 중심점 역할을 한다.

☁️ 로컬과 원격 저장소

git remote -v
git fetch origin
git pull --rebase origin main
git push -u origin feature/login
  • remote: 원격 저장소 주소에 붙인 이름이다. 기본 이름으로 origin을 많이 사용한다.
  • fetch: 원격 이력을 내려받지만 현재 작업 브랜치에는 합치지 않는다.
  • pull: 원격 이력을 내려받고 현재 브랜치에 merge 또는 rebase한다.
  • push: 로컬 커밋과 브랜치를 원격 저장소에 업로드한다.

원격 브랜치는 로컬 브랜치와 별개다. origin/main은 마지막으로 확인한 원격 main의 상태를 나타낸다.

🔄 Pull Request 흐름

GitHub 브랜치 Pull Request 리뷰 병합 흐름

Pull Request(PR)는 한 브랜치의 변경을 다른 브랜치에 병합하기 전에 검토하고 논의하는 단위다.

  1. 기준 브랜치에서 기능 브랜치를 만든다.
  2. 논리적인 단위로 커밋하고 원격에 push한다.
  3. 변경 목적, 구현 내용, 검증 방법을 적어 PR을 연다.
  4. 자동 검사와 코드 리뷰를 통과하도록 수정한다.
  5. 승인된 변경을 기준 브랜치에 병합한다.
  6. 사용이 끝난 기능 브랜치를 정리한다.

PR은 코드만 보여 주는 공간이 아니다. 변경 이유와 의사결정 과정을 남겨 이후 이력을 이해할 수 있게 한다.

👀 코드 리뷰

  • 명확성: 코드가 이름과 구조만으로 의도를 전달하는지 확인한다.
  • 정확성: 요구사항과 예외 상황을 올바르게 처리하는지 확인한다.
  • 안전성: 보안, 데이터 손실, 하위 호환성 위험을 확인한다.
  • 검증: 테스트와 빌드 결과가 변경 범위를 충분히 다루는지 확인한다.
  • 범위: 목적과 무관한 수정이 섞이지 않았는지 확인한다.

리뷰 의견은 사람보다 코드와 동작에 초점을 둔다. 수정이 필수인지 제안인지 구분하면 대화 비용을 줄일 수 있다.

🧩 Issue와 프로젝트 관리

Issue는 버그, 기능, 조사 작업을 추적하는 기본 단위다.

  • 재현 절차와 기대 동작을 구체적으로 기록한다.
  • label로 종류와 우선순위를 분류한다.
  • assignee로 담당자를 표시한다.
  • milestone이나 project로 여러 이슈의 진행 상황을 묶는다.
  • PR 본문에 Closes #123을 쓰면 병합 시 관련 이슈를 자동으로 닫을 수 있다.

🤖 GitHub Actions

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: 24
      - run: npm ci
      - run: npm test

PR마다 포맷, 린트, 테스트, 빌드를 실행하면 사람의 기억에 의존하지 않고 병합 기준을 유지할 수 있다.

🔐 권한과 보안

  • 저장소 권한은 필요한 범위만 부여한다.
  • main 같은 기준 브랜치에는 branch protection과 필수 검사를 설정한다.
  • 비밀값은 코드가 아니라 Actions secrets나 배포 환경 변수에 저장한다.
  • 외부 기여자의 워크플로에서 비밀값이 노출되지 않도록 이벤트와 권한을 확인한다.
  • 의존성 경고와 secret scanning 결과를 정기적으로 확인한다.

💡 GitHub 협업 습관

  • PR 크기를 한 가지 목적에 집중해 리뷰 가능한 수준으로 유지한다.
  • 커밋 메시지에는 변경 내용보다 변경 이유가 드러나게 작성한다.
  • 초안 PR은 방향을 일찍 공유할 때 사용한다.
  • merge, squash, rebase 전략은 저장소 단위로 정해 일관되게 적용한다.
  • README와 기여 가이드에 개발 환경, 테스트 방법, 협업 규칙을 기록한다.

🔗 참고 자료