GitHub Rulesets와 main 보호: required check · review · force push 차단

핵심 원리

Rulesets는 main 보호 정책을 저장소에 강제합니다. required checks와 review가 실제 branch 규칙과 맞는지 확인해야 합니다.

실습 예시

보호할 branch: main
필수 조건:
- Pull Request 경유
- 최소 review 수
- CI required check
- force push 차단
- 필요 시 삭제 차단

실습에서는 결과 화면만 확인하지 않습니다. 어떤 입력과 저장소 상태에서 실행했는지, 성공 조건이 무엇인지, 실패했다면 어느 단계에서 중단됐는지를 함께 기록합니다.

required check가 실제로 병합을 막는지 확인하기

먼저 저장소의 공개/비공개 상태, 계정 요금제, 규칙 편집 권한을 확인합니다. Rulesets는 공개 저장소에서는 Free에서도 사용할 수 있지만 비공개 저장소의 사용 가능 범위는 요금제에 따라 다릅니다. 관리자 또는 규칙 편집 권한 없이 설정을 바꿀 수 있다고 가정하지 않습니다.

10편 workflow가 본인 저장소에서 한 번 실행된 뒤 Settings의 Rules → Rulesets에서 branch ruleset을 구성합니다. 실제 UI와 사용 가능한 옵션은 저장소 권한을 기준으로 확인합니다.

1. 대상 branch를 main으로 지정하고 실습 대상 저장소가 맞는지 확인합니다.
2. Pull Request 경유, force push 차단, 필요한 경우 branch 삭제 차단을 선택합니다.
3. Required status checks에는 실제 실행 결과에 나타난 verify check를 선택합니다. 파일 이름 ci.yml이나 존재하지 않는 test 이름을 입력하는 것으로 대체하지 않습니다.
4. 승인 리뷰 수는 실제 독립 리뷰어가 있는 경우에 맞춥니다. 혼자 학습하면서 자기 PR을 승인할 수 있다고 가정하지 않습니다.
5. bypass 주체와 기존 branch protection을 함께 확인하고 검토한 정책을 Active로 설정합니다. 운영 저장소 설정 변경은 별도 권한과 합의가 필요한 독자 작업입니다.

실패한 PR에서 merge가 차단되고 같은 PR을 수정하여 check가 성공했을 때 조건이 충족되는지 확인합니다. bypass 권한으로 병합한 결과는 정책이 정상 강제됐다는 증거가 아닙니다. 기준 branch 최신 상태 요구는 strict/loose 정책의 차이이며 stale review와 conversation resolution도 서로 다른 조건입니다.

규칙은 여러 ruleset과 기존 protection이 겹쳐 적용될 수 있습니다. 누적된 요구와 가장 제한적인 조건을 확인합니다. check 이름을 바꾸면 ruleset도 실제 이름과 다시 맞춰야 합니다. 서명된 commit 요구는 17편의 키 설정과 검증 범위를 이해한 뒤 선택하고 본 실습에서 무조건 활성화하지 않습니다.

공식 근거: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets · https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets

단계별 확인

ruleset은 PR 요구, required status checks, force push 차단 등을 설정할 수 있습니다.
여러 ruleset/protection이 겹치면 규칙이 누적되고 더 제한적인 조건이 적용될 수 있다는 점을 설명합니다.

각 단계가 끝나면 GitHub UI와 로컬 Git 상태가 같은 사실을 가리키는지 확인합니다. CI라면 workflow log, Ruleset이라면 실제 merge 차단 여부, Release라면 tag가 가리키는 commit을 확인합니다.

git status -sb
git log --oneline -1

독립 학습 변형 과제: 리뷰 없음/CI 실패/두 조건 충족의 세 경우를 표로 만들고 merge 가능 여부를 예측합니다. 실제 권한과 bypass 설정이 다르면 그 차이를 기록합니다.

git-step-10-ci

git status --short
git log --oneline --decorate -8

## 변경 목적

이 변경으로 해결하는 문제와 사용자에게 달라지는 동작을 설명해 주세요.

## 검증

- [ ] 변경 범위의 검증 명령과 실제 결과를 기록했습니다.
- [ ] CI 검사 결과를 확인했습니다.
- [ ] 실패하거나 확인하지 못한 항목과 이유를 기록했습니다.

## 리뷰 참고

검토가 필요한 부분, 연관 이슈, 적용 시 주의할 점을 적어 주세요.

name: CI

on:
  push:
    branches: [main]
  pull_request:

permissions:
  contents: read

jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v7
      - name: Setup Node.js
        uses: actions/setup-node@v7
        with:
          node-version: "24.x"
      - name: Setup pnpm
        uses: pnpm/action-setup@v6
        with:
          version: "11.19.0"
          cache: true
      - name: Install dependencies
        run: pnpm install --frozen-lockfile
      - name: Lint
        run: pnpm lint
      - name: Build
        run: pnpm build

# git-step-11-protected-main 문서 체크포인트

이 ZIP은 Git·GitHub 실습 안내와 관련 설정 파일을 모은 자료입니다. `.git` 이력, 실제 branch/tag/stash/worktree, 원격 저장소, 사용자 계정이나 TaskFlow 앱 전체를 포함하지 않습니다. 별도의 개발환경 과정 TaskFlow 프로젝트에서 실습 안내를 읽고 명령을 단계별로 적용하세요. 이 폴더 자체를 완성된 Git 저장소로 간주하거나 명령을 한꺼번에 실행하지 마세요.

01~13 필수 과정의 이 회차까지 문서를 누적합니다.

.github/PULL_REQUEST_TEMPLATE.md는 실제 프로젝트에 검토하여 복사할 PR 작성 양식입니다. CODEOWNERS의 실제 사용자·팀은 저장소 권한에 맞춰 직접 정하며 가짜 소유자를 넣은 파일은 포함하지 않습니다.

.github/workflows/ci.yml은 개발환경 과정 TaskFlow의 pnpm@11.19.0, Node 24.x, lint/build 스크립트를 기준으로 합니다. 기존 package.json/pnpm-lock.yaml이 있는 프로젝트 루트에 적용합니다. 이 ZIP 루트에서는 pnpm install/build를 실행하는 구조가 아닙니다. 원격 Actions 실행·보호 규칙 설정은 검증하지 않았습니다.

검증 범위는 명령 문법·설정 형식·공식 문서 및 기존 프로젝트 스크립트 대조입니다. 실제 init/commit/branch/stash/worktree/reset/rebase/merge/push/PR/Release/서명 작업을 수행했다는 기록이 아닙니다. 개인 키·토큰·비밀번호는 포함하지 않습니다.

# Git·GitHub 01 실습 안내

이 파일은 독자가 상태를 확인하며 따라갈 Markdown 문서입니다. 자동 실행 스크립트나 검수 과정에서 실행한 Git 이력 로그가 아닙니다.

## 첫 저장소부터 원격 연결까지

Git 공식 설치 안내에서 운영체제에 맞는 Git을 설치합니다. Windows 명령 예제는 Git Bash 기준입니다. 이후 회차도 같은 셸을 사용합니다. 먼저 개발환경 과정에서 만든 TaskFlow 폴더를 편집기로 열고 그 폴더에서 터미널을 엽니다. 이미 .git이 있는 프로젝트라면 아래 init을 반복하기보다 현재 이력과 브랜치를 먼저 확인합니다.

```bash
git --version
git init -b main
git status --short
```

이름과 이메일은 이 저장소의 commit 작성자 정보입니다. GitHub 인증 비밀번호가 아닙니다. 공개 이메일을 원하지 않으면 GitHub Settings의 Emails에서 본인의 noreply 주소를 확인합니다. 아래 입력은 실제 값을 화면에 재출력하지 않고 저장소 로컬 설정에만 기록합니다.

```bash
read -r -p "commit 작성자 이름: " GIT_AUTHOR_LABEL
read -r -p "commit 작성자 이메일 또는 본인 noreply 주소: " GIT_AUTHOR_MAIL
if [ -n "$GIT_AUTHOR_LABEL" ] && [ -n "$GIT_AUTHOR_MAIL" ]; then
  git config --local user.name "$GIT_AUTHOR_LABEL"
  git config --local user.email "$GIT_AUTHOR_MAIL"
else
  printf '%s\n' '빈 작성자 정보로 진행하지 않습니다.'
fi
```

편집기에서 README.md에 TaskFlow의 목적 한 줄을 작성합니다. 기존 파일은 덮어쓰지 않고 내용을 읽고 수정합니다. .gitignore에는 기존 개발환경의 node_modules, 빌드 산출물, 실제 환경변수 파일 제외 규칙을 유지합니다. 첫 commit은 README만 명시적으로 선택합니다.

```bash
git status --short
git add README.md
git diff --cached
git commit -m "docs: describe TaskFlow"
git log --oneline -1
```

처음에는 README가 untracked라서 일반 git diff에 나오지 않을 수 있습니다. add 후 cached diff는 첫 commit에 들어갈 내용을 보여 줍니다. 이제 README에 실행 방법 한 줄을 추가해 add하고, commit하기 전에 다른 설명 한 줄을 더 수정합니다.

```bash
git add README.md
git status --short
git diff
git diff --cached
```

이때 예상하는 MM의 첫 M은 staging, 두 번째 M은 staging 이후 작업 트리 변경입니다. 두 diff를 비교한 뒤 두 변경 모두 포함하려면 다시 add하고 두 번째 commit을 만듭니다.

```bash
git add README.md
git diff --cached
git commit -m "docs: add TaskFlow usage"
```

GitHub에서는 본인 계정에 빈 저장소를 만들고 README나 초기 commit을 추가하지 않습니다. 저장소 화면의 HTTPS 또는 SSH 주소를 복사합니다. HTTPS는 Git Credential Manager 등 공식 인증 흐름을, SSH는 이미 등록한 키를 사용합니다. 비밀번호나 토큰을 URL에 넣지 않습니다. 아래는 독자가 본인 원격 저장소를 연결할 때 실행하는 절차이며 이 글의 검수에서 push한 결과가 아닙니다.

```bash
read -r -p "본인의 빈 GitHub 저장소 clone 주소: " TASKFLOW_REMOTE
if [ -n "$TASKFLOW_REMOTE" ]; then
  git remote add origin "$TASKFLOW_REMOTE"
else
  printf '%s\n' '원격 주소가 없어 연결하지 않습니다.'
fi
git remote -v
```

origin이 이미 존재하면 add 실패를 무시하지 말고 기존 주소가 본인의 대상인지 확인합니다. 주소와 commit 내용을 검토한 뒤에만 첫 push를 실행합니다.

```bash
git push -u origin main
git status -sb
git rev-parse HEAD
git ls-remote origin refs/heads/main
```

마지막 두 출력의 commit ID가 같고 GitHub 파일 화면이 일치하면 첫 연결 기준을 충족합니다. 빈 원격이 아니어서 rejected가 발생했다면 강제 push하지 않고 4편의 fetch/이력 비교로 이동합니다. init 전에는 status가 실패하고 첫 commit 전에는 log가 실패하는 것이 정상일 수 있습니다.

공식 근거: https://git-scm.com/docs/git-init · https://git-scm.com/docs/git-add · https://git-scm.com/docs/git-commit · https://docs.github.com/en/get-started/git-basics/set-up-git

## 체크포인트 기준

git-step-01-first-push: 위 실습의 관찰 기준을 본인의 연습 환경에서 확인한 뒤 사용합니다. 이 ZIP을 내려받았다는 사실만으로 실습 완료가 성립하지 않습니다.

# Git·GitHub 02 실습 안내

이 파일은 독자가 상태를 확인하며 따라갈 Markdown 문서입니다. 자동 실행 스크립트나 검수 과정에서 실행한 Git 이력 로그가 아닙니다.

## 목적별 commit을 만드는 실습

1편 이후 README.md에 서로 떨어진 두 문단을 수정합니다. 하나는 실행 방법, 다른 하나는 오타 수정으로 구분합니다. 이미 공유한 commit을 재작성하지 않도록 이 실습에서는 아직 push하지 않은 새 변경만 사용합니다.

```bash
git diff --stat
git diff -- README.md
git add -p README.md
git diff --cached
git diff -- README.md
```

대화형 질문에서 y는 현재 hunk를 staging하고 n은 남깁니다. 한 hunk에 섞였으면 s로 분할할 수 있는지 확인하고, 분할되지 않으면 편집기에서 변경을 다시 나눕니다. cached diff에 첫 목적만 남았을 때 commit하고 나머지 변경을 두 번째 commit으로 만듭니다.

```bash
git commit -m "docs: clarify TaskFlow startup"
git add README.md
git diff --cached
git commit -m "docs: correct wording"
git log --oneline -2
```

이어서 README 한 줄을 다시 수정하고 git add README.md로 stage합니다. 이 추가 변경을 다음 명령으로 index에서만 되돌립니다. 작업 트리의 수정은 남아 있는지 status와 diff로 확인합니다.

```bash
git add README.md
git restore --staged README.md
git status --short
git diff -- README.md
```

마지막 commit의 메시지만 바꾸려면 staged 변경이 없는지 확인한 다음 실행합니다. 방금 unstage한 작업 트리 수정은 이 amend에 포함되지 않고 그대로 남습니다. amend는 새 commit을 만들어 ID를 바꾸며 이미 push한 이력에는 기본 절차로 적용하지 않습니다. --no-edit도 staged 내용까지 기존 commit에 합칠 수 있습니다.

```bash
git diff --cached
git rev-parse HEAD
git commit --amend -m "docs: fix TaskFlow guide wording"
git rev-parse HEAD
git show --stat HEAD
```

.gitignore는 미추적 파일의 추가를 막는 규칙입니다. 이미 추적한 일반 파일을 추적에서 빼는 git rm --cached는 별도의 삭제 commit을 만들므로 대상과 영향을 확인해야 합니다. 비밀이 이미 공개됐다면 ignore 변경만으로 과거 이력이 사라지지 않습니다. 우선 자격증명을 폐기·교체하고 저장소 관리 절차로 대응합니다. 학습 중 실제 비밀을 만들거나 commit하지 않습니다.

공식 근거: https://git-scm.com/docs/git-add · https://git-scm.com/docs/git-restore · https://git-scm.com/docs/git-commit · https://git-scm.com/docs/gitignore

## 체크포인트 기준

git-step-02-clean-commit: 위 실습의 관찰 기준을 본인의 연습 환경에서 확인한 뒤 사용합니다. 이 ZIP을 내려받았다는 사실만으로 실습 완료가 성립하지 않습니다.

# Git·GitHub 03 실습 안내

이 파일은 독자가 상태를 확인하며 따라갈 Markdown 문서입니다. 자동 실행 스크립트나 검수 과정에서 실행한 Git 이력 로그가 아닙니다.

## fast-forward와 merge commit 비교 실습

working tree가 깨끗한지 먼저 확인합니다. 아래 학습용 branch 이름이 이미 있으면 중단하고 기존 작업을 확인합니다. 먼저 feature/a를 만들고 편집기에서 새 문서 docs/branch-a.md에 기능 설명을 작성합니다. docs 폴더가 없으면 편집기로 만듭니다.

```bash
git status --short
git switch -c feature/a
```

파일 작성 후 해당 파일만 commit하고 main으로 돌아와 병합합니다. 이 사이 main에 다른 commit을 만들지 않습니다.

```bash
git add docs/branch-a.md
git commit -m "docs: add branch A notes"
git switch main
git merge --ff-only feature/a
git log --graph --oneline --decorate -5
```

새 merge commit 없이 main이 feature/a의 끝으로 이동하는 것이 fast-forward입니다. 다음에는 같은 main에서 feature/b를 만들고 docs/branch-b.md를 작성해 commit합니다.

```bash
git switch -c feature/b
```

파일 작성 뒤 다음을 실행합니다.

```bash
git add docs/branch-b.md
git commit -m "docs: add branch B notes"
git switch main
```

main에서는 다른 파일 docs/main-notes.md를 작성해 commit합니다. 양쪽에 서로 다른 commit이 생긴 다음 feature/b를 병합합니다.

```bash
git add docs/main-notes.md
git commit -m "docs: add main notes"
git merge feature/b -m "Merge branch feature/b"
git log --graph --oneline --decorate --all -10
git show --no-patch --format='%h %p' HEAD
```

마지막 commit의 부모 ID가 두 개라면 merge commit입니다. --no-ff는 fast-forward가 가능해도 merge commit을 만들도록 선택하는 옵션이며, 이번 두 번째 예제는 이미 갈라진 이력이므로 없어도 merge commit이 생깁니다. 병합을 확인한 branch만 git branch -d로 정리할 수 있지만 삭제는 실습 완료의 필수 조건이 아닙니다.

공식 근거: https://git-scm.com/docs/git-switch · https://git-scm.com/docs/git-merge · https://git-scm.com/docs/git-branch

## 체크포인트 기준

git-step-03-branch-merge: 위 실습의 관찰 기준을 본인의 연습 환경에서 확인한 뒤 사용합니다. 이 ZIP을 내려받았다는 사실만으로 실습 완료가 성립하지 않습니다.

# Git·GitHub 04 실습 안내

이 파일은 독자가 상태를 확인하며 따라갈 Markdown 문서입니다. 자동 실행 스크립트나 검수 과정에서 실행한 Git 이력 로그가 아닙니다.

## 원격 이력을 확인한 뒤 동기화하기

origin은 저장소 주소의 별명이고 origin/main은 마지막 fetch 시점에 관찰한 원격 main입니다. 실시간 서버 상태 자체가 아닙니다. 기존 TaskFlow 저장소에서 먼저 다음을 확인합니다.

```bash
git status -sb
git remote -v
git branch -vv
git fetch origin
git log --graph --oneline --decorate --all -15
git log --left-right --oneline main...origin/main
```

fetch는 원격 정보를 가져오지만 현재 작업 트리를 자동 병합하지 않습니다. 마지막 비교에서 왼쪽은 local에만, 오른쪽은 원격 추적 branch에만 있는 commit입니다. working tree가 깨끗하고 local main에 고유 commit이 없을 때만 다음처럼 fast-forward 동기화를 선택합니다.

```bash
git switch main
git pull --ff-only origin main
git status -sb
```

양쪽 이력이 갈라지면 --ff-only는 실패합니다. 이때 실패를 강제 push로 덮지 않습니다. 3편의 merge 또는 8편의 공유 여부를 고려한 rebase 중 팀 정책에 맞는 절차를 정합니다. branch의 upstream이 없다면 대상이 맞는지 확인한 뒤 git branch --set-upstream-to=origin/main main을 사용할 수 있습니다.

clone을 비교하려면 기존 프로젝트 안이 아닌 별도 상위 폴더에서 진행합니다. taskflow-peer 폴더가 이미 있으면 실행하지 않습니다. 본인 원격의 읽기 권한을 확인하고 실제 clone 주소를 입력합니다.

```bash
read -r -p "본인의 GitHub clone 주소: " TASKFLOW_REMOTE
if [ -n "$TASKFLOW_REMOTE" ] && [ ! -e taskflow-peer ]; then
  git clone "$TASKFLOW_REMOTE" taskflow-peer
else
  printf '%s\n' '주소와 새 대상 폴더를 확인하세요.'
fi
```

두 clone의 branch와 remote-tracking 상태를 비교합니다. push rejected를 재현하려면 본인의 연습용 원격에 한쪽 clone에서 변경을 먼저 push한 뒤 다른 clone에서 이전 상태를 기준으로 push하는 순서를 사용합니다. 이는 원격을 변경하는 선택 실습입니다. 검수 과정에서는 원격을 만들거나 push하지 않았습니다.

공식 근거: https://git-scm.com/docs/git-fetch · https://git-scm.com/docs/git-pull · https://git-scm.com/docs/git-clone · https://git-scm.com/docs/git-push

## 체크포인트 기준

git-step-04-remote-sync: 위 실습의 관찰 기준을 본인의 연습 환경에서 확인한 뒤 사용합니다. 이 ZIP을 내려받았다는 사실만으로 실습 완료가 성립하지 않습니다.

# Git·GitHub 05 실습 안내

이 파일은 독자가 상태를 확인하며 따라갈 Markdown 문서입니다. 자동 실행 스크립트나 검수 과정에서 실행한 Git 이력 로그가 아닙니다.

## 같은 줄의 충돌을 재현하고 해결하기

독자의 연습용 저장소에서만 진행합니다. clean main의 README.md에 같은 기준 문장이 commit되어 있어야 합니다. feature/conflict-demo 이름이 이미 있으면 기존 작업을 확인한 뒤 새 이름을 선택합니다.

```bash
git switch main
git status --short
git switch -c feature/conflict-demo
```

편집기에서 README의 한 문장을 기능 설명으로 바꾸고 commit합니다. main으로 돌아와 같은 원래 문장을 다른 설명으로 수정하고 별도 commit합니다. 두 문장을 서로 다른 줄에 추가하면 충돌이 발생하지 않을 수 있으므로 같은 줄을 바꿉니다.

```bash
git add README.md
git commit -m "docs: explain feature behavior"
git switch main
```

main 쪽의 같은 줄 수정 후 다음을 실행합니다.

```bash
git add README.md
git commit -m "docs: clarify main behavior"
git switch feature/conflict-demo
git merge main
git status
git diff --name-only --diff-filter=U
git diff -- README.md
```

충돌이 있다면 README에서 <<<<<<<, =======, >>>>>>>가 구분하는 두 의도를 읽습니다. 최종 요구에 맞는 한 문장 또는 두 설명으로 편집하고 marker를 제거합니다. 문서를 확인한 다음 해당 파일만 stage하고 병합 commit을 만듭니다.

```bash
git add README.md
git diff --cached
git commit -m "docs: resolve explanation conflict"
git status --short
```

해결 방향이 불명확하면 진행 중인 merge에서만 git merge --abort를 선택합니다. 이미 병합을 완료한 뒤 abort하는 명령이 아닙니다. merge 시작 전 미완료 변경이 있으면 abort가 원래 상태를 완전히 복원하지 못할 수 있으므로 clean 상태로 시작합니다.

본인 원격과 공개할 변경을 검토한 뒤 feature/conflict-demo를 push하고 GitHub에서 base main, compare feature/conflict-demo인 PR을 만듭니다. Files changed에서 marker가 남지 않았는지 확인하고 프로젝트의 lint/build를 실행합니다. 자신의 PR은 스스로 승인하는 리뷰를 남길 수 없으므로 혼자 학습하면 self-review 결과만 기록하고, 실제 승인 검증은 다른 권한 있는 리뷰어가 있을 때 수행합니다. 병합 후 local main은 fetch/pull로 별도 갱신합니다.

공식 근거: https://git-scm.com/docs/git-merge · https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-using-the-command-line

## 체크포인트 기준

git-step-05-conflict-pr: 위 실습의 관찰 기준을 본인의 연습 환경에서 확인한 뒤 사용합니다. 이 ZIP을 내려받았다는 사실만으로 실습 완료가 성립하지 않습니다.

# Git·GitHub 06 실습 안내

이 파일은 독자가 상태를 확인하며 따라갈 Markdown 문서입니다. 자동 실행 스크립트나 검수 과정에서 실행한 Git 이력 로그가 아닙니다.

## 복구 대상별로 명령을 선택하기

이 절은 모든 명령을 연속 실행하는 절차가 아닙니다. 현재 작업을 보존한 연습용 복제본에서 한 상황씩 비교합니다. 파일 내용, staging, branch 위치, 공유 이력은 서로 다른 복구 대상입니다.

| 대상 | 선택 | 남는 상태 |
| --- | --- | --- |
| staging만 해제 | git restore --staged README.md | 작업 트리 수정 유지 |
| 추적 파일의 미commit 수정 취소 | git restore README.md | 기본적으로 index 내용으로 복원, 수정 유실 가능 |
| branch만 이전 commit으로 | git reset --soft HEAD~1 | index·작업 트리 유지 |
| branch와 index를 이전 commit으로 | git reset --mixed HEAD~1 | 작업 트리 유지, staging 해제 |
| branch·index·작업 트리를 이전 commit으로 | git reset --hard HEAD~1 | 추적 파일 수정 유실 가능 |
| 공유 commit의 효과 취소 | git revert | 취소 변경을 새 commit으로 추가 |

soft/mixed/hard 비교는 각각 같은 세-commit 시작 상태의 별도 복제본에서 수행해야 합니다. 순서대로 실행하면 매번 HEAD가 달라져 비교가 성립하지 않습니다. --hard와 clean은 실제 작업을 잃을 수 있으므로 이 자료의 필수 실행 절차에 넣지 않습니다.

공유 commit을 취소하는 예제는 단일 부모의 일반 commit 하나를 대상으로 합니다. 먼저 log에서 대상 ID를 직접 확인한 뒤 입력합니다.

```bash
git status --short
git log --oneline -8
read -r -p "취소할 일반 commit ID: " REVERT_COMMIT
if [ -n "$REVERT_COMMIT" ]; then
  git show --stat "$REVERT_COMMIT"
fi
```

출력에서 대상·내용을 확인하고 clean 상태일 때만 아래를 선택합니다. merge commit은 mainline 선택이 필요한 별도 경우라 이 예제에 넣지 않습니다.

```bash
if [ -n "$REVERT_COMMIT" ]; then
  git revert "$REVERT_COMMIT"
fi
git log --oneline -3
git status --short
```

충돌이 나면 파일을 해결·stage한 후 git revert --continue를 사용하거나 중단하려면 git revert --abort를 선택합니다. 둘을 연속 실행하지 않습니다. 보호된 main은 revert 변경도 별도 branch와 PR로 검토합니다.

잃어버린 commit은 reflog에서 찾고 show로 내용을 확인한 다음 새 구조용 branch에 이름을 붙여 보존할 수 있습니다. reflog는 로컬 기록이며 영구 백업이 아닙니다.

```bash
git reflog --date=local -15
read -r -p "보존할 commit ID: " RECOVERY_COMMIT
if [ -n "$RECOVERY_COMMIT" ]; then
  git show --stat "$RECOVERY_COMMIT"
fi
```

확인한 ID가 맞을 때만 git branch rescue/recovered "$RECOVERY_COMMIT"로 새 이름을 붙입니다. 같은 branch가 있으면 덮어쓰지 않습니다. status/log로 결과를 다시 확인합니다.

공식 근거: https://git-scm.com/docs/git-restore · https://git-scm.com/docs/git-reset · https://git-scm.com/docs/git-revert · https://git-scm.com/docs/git-reflog

## 체크포인트 기준

git-step-06-recovery: 위 실습의 관찰 기준을 본인의 연습 환경에서 확인한 뒤 사용합니다. 이 ZIP을 내려받았다는 사실만으로 실습 완료가 성립하지 않습니다.

# Git·GitHub 07 실습 안내

이 파일은 독자가 상태를 확인하며 따라갈 Markdown 문서입니다. 자동 실행 스크립트나 검수 과정에서 실행한 Git 이력 로그가 아닙니다.

## 임시 변경과 commit을 따로 다루는 실습

clean main에서 feature/context-demo를 만들고 README.md를 아직 commit하지 않은 상태로 수정합니다. 새 branch 이름이 이미 있으면 먼저 기존 작업을 확인합니다.

```bash
git switch -c feature/context-demo
```

README 수정 후 상태를 확인하고 stash합니다. 기본 stash는 추적 파일의 변경을 대상으로 하며 새 파일도 포함하려면 의도한 파일인지 먼저 확인한 후 -u를 선택합니다. 실제 비밀 파일을 stash에 넣지 않습니다.

```bash
git status --short
git stash push -m "TaskFlow context exercise"
git stash list
git stash show -p 'stash@{0}'
git switch main
git switch -c hotfix/context-demo
```

편집기로 docs/hotfix-note.md를 작성하고 작은 hotfix commit을 만듭니다. 그 ID를 show/log로 확인한 뒤 feature branch로 돌아옵니다.

```bash
git add docs/hotfix-note.md
git commit -m "docs: record hotfix note"
HOTFIX_COMMIT=$(git rev-parse HEAD)
git show --stat "$HOTFIX_COMMIT"
git switch feature/context-demo
git cherry-pick "$HOTFIX_COMMIT"
```

cherry-pick은 원래 commit을 없애거나 이동하지 않고 해당 변경을 현재 branch에 적용해 commit을 만듭니다. 상태에 따라 ID가 달라질 수 있습니다. 충돌이 생기면 해결 후 stage하고 git cherry-pick --continue, 중단하려면 --abort를 선택합니다.

먼저 cherry-pick을 끝내고 clean 상태를 확인한 다음 보관한 README 변경을 복원합니다.

```bash
git status --short
git stash list
git stash apply 'stash@{0}'
git diff -- README.md
```

apply는 보관 항목을 남깁니다. pop은 성공적으로 적용하면 항목을 제거하지만 충돌하면 남을 수 있습니다. 따라서 본 실습은 apply로 확인하고 의도한 변경을 commit한 뒤, 정확한 stash 항목을 재확인한 경우에만 drop을 선택합니다. 다른 작업의 stash를 일괄 삭제하지 않습니다.

공식 근거: https://git-scm.com/docs/git-stash · https://git-scm.com/docs/git-cherry-pick

## 체크포인트 기준

git-step-07-context-switch: 위 실습의 관찰 기준을 본인의 연습 환경에서 확인한 뒤 사용합니다. 이 ZIP을 내려받았다는 사실만으로 실습 완료가 성립하지 않습니다.

# Git·GitHub 08 실습 안내

이 파일은 독자가 상태를 확인하며 따라갈 Markdown 문서입니다. 자동 실행 스크립트나 검수 과정에서 실행한 Git 이력 로그가 아닙니다.

## 공유하지 않은 branch의 이력 정리

이 실습은 다른 사람이 기반으로 사용하지 않고 아직 push하지 않은 feature branch에서 수행합니다. main에 직접 적용하지 않습니다. clean 상태에서 feature/rebase-demo를 만들고 README의 작은 변경을 세 번 나누어 commit합니다. 각 commit은 파일을 실제로 수정한 뒤 add와 commit을 실행해 만듭니다.

```bash
git switch main
git switch -c feature/rebase-demo
```

세 commit을 만든 다음 log에서 대상 세 개를 확인합니다. 안전한 비교 기준으로 branch를 하나 보존할 수 있습니다. 이름이 이미 있으면 재사용하지 않습니다.

```bash
git status --short
git log --oneline -4
git branch backup/rebase-demo
git rebase -i HEAD~3
```

편집기에서 첫 commit은 pick으로 남기고 두 번째는 squash 또는 fixup으로 첫 commit에 합치며 세 번째는 pick으로 유지하면 세 commit을 두 개로 정리할 수 있습니다. squash는 메시지를 편집하고 fixup은 합쳐지는 commit의 메시지를 버립니다. drop은 변경을 제외하므로 이번 실습에서는 선택하지 않습니다. 저장·종료 뒤 diff와 log로 최종 파일 내용이 유지됐는지 확인합니다.

```bash
git log --graph --oneline --decorate -6
git diff backup/rebase-demo HEAD
```

내용 변경 없이 이력만 정리했다면 마지막 diff는 비어 있어야 합니다. 최신 main 위로 재배치할 필요가 있으면 fetch 후 feature branch에서 다음을 선택합니다.

```bash
git fetch origin
git rebase origin/main
```

충돌한 경우에만 파일을 편집하고 해당 파일을 add한 뒤 git rebase --continue를 실행합니다. 작업을 포기하려면 진행 중인 rebase에서 --abort를 선택합니다. 성공 후 --continue와 --abort를 연속 실행하는 절차가 아닙니다. rebase에서 ours/theirs의 의미를 일반 merge와 기계적으로 동일시하지 않습니다.

이미 공유한 branch의 이력 재작성은 별도 합의가 필요합니다. --force-with-lease는 원격의 예상 상태를 검사하지만 무조건 안전한 강제 push가 아닙니다. 백그라운드 fetch 등의 영향과 다른 사용자의 작업을 확인해야 하며, 본 실습은 강제 push 없이 로컬 비교로 완료합니다.

공식 근거: https://git-scm.com/docs/git-rebase · https://git-scm.com/docs/git-push

## 체크포인트 기준

git-step-08-rebase: 위 실습의 관찰 기준을 본인의 연습 환경에서 확인한 뒤 사용합니다. 이 ZIP을 내려받았다는 사실만으로 실습 완료가 성립하지 않습니다.

# Git·GitHub 09 실습 안내

이 파일은 독자가 상태를 확인하며 따라갈 Markdown 문서입니다. 자동 실행 스크립트나 검수 과정에서 실행한 Git 이력 로그가 아닙니다.

## Draft PR부터 리뷰 결과까지

작은 변경이 commit된 feature branch에서 시작합니다. 먼저 최신 base를 확인하고 PR에 포함될 차이를 읽습니다.

```bash
git fetch origin
git status --short
git diff origin/main...HEAD
git log origin/main..HEAD --oneline
git branch --show-current
```

현재 branch가 의도한 feature인지, diff에 비밀값이나 무관한 변경이 없는지 확인합니다. 원격 반영을 원하는 독자는 다음처럼 현재 branch 이름을 확인하여 push합니다. 빈 이름은 detached HEAD이므로 중단합니다.

```bash
PR_BRANCH=$(git branch --show-current)
if [ -n "$PR_BRANCH" ] && [ "$PR_BRANCH" != main ]; then
  git push -u origin "$PR_BRANCH"
else
  printf '%s\n' '검토한 feature branch에서 진행하세요.'
fi
```

GitHub 저장소의 Pull requests에서 base main과 compare 현재 branch를 선택하고 Draft로 생성합니다. 제공한 .github/PULL_REQUEST_TEMPLATE.md를 참고해 변경 이유, 검증 명령과 실제 결과, 영향 범위를 적습니다. 수행하지 않은 테스트를 통과했다고 쓰지 않습니다.

Files changed에서 줄별 self-review를 하고 필요한 수정 commit을 같은 branch에 push하면 PR이 갱신됩니다. 검토 준비가 끝나면 Ready for review로 전환합니다. 다른 리뷰어는 Comment, Approve, Request changes 중 목적에 맞는 결과를 남깁니다. 작성자는 자신의 PR을 승인할 수 없습니다. 대화 해결 표시는 실제 요청 반영과 구분하여 확인합니다.

merge commit은 branch 구조를 남기고, squash merge는 PR 변경을 한 commit으로 정리하며, rebase merge는 base 위에 commit들을 새로 재배치합니다. 허용 방식과 보호 규칙을 확인한 뒤 한 방식을 선택합니다. 병합 후 local main을 fetch와 --ff-only pull로 갱신합니다.

CODEOWNERS에는 실제 저장소 쓰기 권한이 있는 사용자 또는 접근 가능한 팀을 지정합니다. .github/CODEOWNERS 등의 지원 위치에 파일을 두고 실제 파일 패턴과 owner를 설정해야 하며 가짜 계정을 복사해서는 안 됩니다. base branch의 CODEOWNERS가 리뷰 요청에 사용되고, 승인 강제는 별도의 보호 규칙이 필요합니다. CODEOWNERS 자체는 파일 접근 권한을 부여하거나 변경을 차단하는 보안 경계가 아닙니다.

공식 근거: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request · https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners

## 체크포인트 기준

git-step-09-reviewed-pr: 위 실습의 관찰 기준을 본인의 연습 환경에서 확인한 뒤 사용합니다. 이 ZIP을 내려받았다는 사실만으로 실습 완료가 성립하지 않습니다.

# Git·GitHub 10 실습 안내

이 파일은 독자가 상태를 확인하며 따라갈 Markdown 문서입니다. 자동 실행 스크립트나 검수 과정에서 실행한 Git 이력 로그가 아닙니다.

## 실제 package script에 맞춘 CI 구성

이 과정이 이어받는 개발환경 TaskFlow는 pnpm 11.19.0, Node 24 이상, dev/build/lint script를 사용합니다. 따라서 존재하지 않는 npm test나 typecheck를 실행하지 않습니다. test script를 별도로 추가한 프로젝트만 해당 검사를 workflow에 넣습니다. 기존 프로젝트가 npm이라면 lockfile과 package manager를 그대로 유지하고 별도 조정해야 합니다.

먼저 package.json의 packageManager, engines, scripts와 pnpm-lock.yaml을 확인합니다. 독자의 준비된 앱에서 아래 검사가 각각 성공하는지 확인하고 실패 단계와 첫 오류를 기록합니다.

```bash
node --version
pnpm --version
pnpm install --frozen-lockfile
pnpm lint
pnpm build
```

전체 코드에 제공한 .github/workflows/ci.yml을 저장소 루트의 같은 경로에 추가합니다. checkout과 setup-node는 공식 v7, pnpm/action-setup은 공식 v6를 사용합니다. setup-node가 Node 24를 준비한 다음 pnpm을 설치하고 캐시를 구성합니다. cache hit 여부와 관계없이 frozen-lockfile install은 실행합니다. permissions의 contents: read는 이 검증 workflow에 필요한 읽기 권한만 부여합니다.

workflow는 pull_request와 main push를 검사하며 job ID는 verify입니다. PR마다 install → lint → build가 순서대로 실행됩니다. 이 예제는 실제 배포 단계를 포함하지 않습니다. pull_request_target으로 바꿔 신뢰하지 않는 PR 코드를 높은 권한으로 실행하지 않습니다. 비밀값은 YAML이나 로그에 넣지 않습니다.

독자가 본인 feature branch에 파일을 commit·push하면 PR의 Checks 또는 Actions에서 workflow를 열 수 있습니다. 첫 실패 step을 펼쳐 package manager·lockfile·lint·build 중 어느 단계인지 확인합니다. 수정 commit을 같은 PR에 올려 다시 성공하는지 확인합니다. 검수를 위해 원격 Actions를 실행하지 않았으므로 이 글에 성공 run URL을 가정하지 않습니다.

공식 근거: https://github.com/actions/checkout · https://github.com/actions/setup-node · https://github.com/pnpm/action-setup · https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions

## 체크포인트 기준

git-step-10-ci: 위 실습의 관찰 기준을 본인의 연습 환경에서 확인한 뒤 사용합니다. 이 ZIP을 내려받았다는 사실만으로 실습 완료가 성립하지 않습니다.

# Git·GitHub 11 실습 안내

이 파일은 독자가 상태를 확인하며 따라갈 Markdown 문서입니다. 자동 실행 스크립트나 검수 과정에서 실행한 Git 이력 로그가 아닙니다.

## required check가 실제로 병합을 막는지 확인하기

먼저 저장소의 공개/비공개 상태, 계정 요금제, 규칙 편집 권한을 확인합니다. Rulesets는 공개 저장소에서는 Free에서도 사용할 수 있지만 비공개 저장소의 사용 가능 범위는 요금제에 따라 다릅니다. 관리자 또는 규칙 편집 권한 없이 설정을 바꿀 수 있다고 가정하지 않습니다.

10편 workflow가 본인 저장소에서 한 번 실행된 뒤 Settings의 Rules → Rulesets에서 branch ruleset을 구성합니다. 실제 UI와 사용 가능한 옵션은 저장소 권한을 기준으로 확인합니다.

1. 대상 branch를 main으로 지정하고 실습 대상 저장소가 맞는지 확인합니다.
2. Pull Request 경유, force push 차단, 필요한 경우 branch 삭제 차단을 선택합니다.
3. Required status checks에는 실제 실행 결과에 나타난 verify check를 선택합니다. 파일 이름 ci.yml이나 존재하지 않는 test 이름을 입력하는 것으로 대체하지 않습니다.
4. 승인 리뷰 수는 실제 독립 리뷰어가 있는 경우에 맞춥니다. 혼자 학습하면서 자기 PR을 승인할 수 있다고 가정하지 않습니다.
5. bypass 주체와 기존 branch protection을 함께 확인하고 검토한 정책을 Active로 설정합니다. 운영 저장소 설정 변경은 별도 권한과 합의가 필요한 독자 작업입니다.

실패한 PR에서 merge가 차단되고 같은 PR을 수정하여 check가 성공했을 때 조건이 충족되는지 확인합니다. bypass 권한으로 병합한 결과는 정책이 정상 강제됐다는 증거가 아닙니다. 기준 branch 최신 상태 요구는 strict/loose 정책의 차이이며 stale review와 conversation resolution도 서로 다른 조건입니다.

규칙은 여러 ruleset과 기존 protection이 겹쳐 적용될 수 있습니다. 누적된 요구와 가장 제한적인 조건을 확인합니다. check 이름을 바꾸면 ruleset도 실제 이름과 다시 맞춰야 합니다. 서명된 commit 요구는 17편의 키 설정과 검증 범위를 이해한 뒤 선택하고 본 실습에서 무조건 활성화하지 않습니다.

공식 근거: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets · https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets

## 체크포인트 기준

git-step-11-protected-main: 위 실습의 관찰 기준을 본인의 연습 환경에서 확인한 뒤 사용합니다. 이 ZIP을 내려받았다는 사실만으로 실습 완료가 성립하지 않습니다.

git-step-11-protected-main

다음 학습

12 Git tag와 GitHub Release