Ship

Ship 파이프라인 (Commit → Push → PR → Merge)

$ARGUMENTS 를 파싱해 모드를 결정하고 전체 파이프라인을 실행한다.

브랜치 전략 자동 적응: 리포지토리에 develop 브랜치가 있으면 git-flow(feature → develop → main)로, 없으면 GitHub Flow(feature → main)로 자동 동작한다. 별도 설정 없이 현재 리포의 브랜치 구조를 감지해 맞춘다.

파이프라인 구성

[파이프라인 A]  --dev  : feature/* → develop
[파이프라인 B]  --main : develop   → main

[GitHub Flow]   develop 브랜치 없음 → feature/* → main

[체인 모드]     --main + feature/* + 미push 변경사항
                = 파이프라인 A 자동 실행 → 완료 후 파이프라인 B 자동 실행

Step 0 — $ARGUMENTS 파싱

$ARGUMENTS에서 아래 항목을 순서대로 추출한다:

두 타겟 플래그 동시 입력 시 → 즉시 중단: "플래그는 --dev 또는 --main 중 하나만 사용 가능합니다."

Step 1 — 사전 확인 및 모드 결정

1-1. 기본 정보 수집

git branch --show-current          # 현재 브랜치
git status --short                 # 변경사항 여부
git remote get-url origin          # owner/repo 파싱
git ls-remote --heads origin develop  # develop 브랜치 존재 여부

origin 미설정 시 → 즉시 중단: "git remote add origin 후 재시도하세요."

1-2. 모드 결정 분기

develop 브랜치 없음?
  └─▶ GitHub Flow MODE (Step 2L)

develop 브랜치 있음?
  ├─ 현재: main/master → 즉시 중단
  ├─ 현재: develop + --dev 플래그 → 즉시 중단
  │        ("develop에서 --dev 불가. feature 브랜치에서 사용하세요.")
  │
  ├─ 현재: develop + (--main | 플래그 없음)
  │   └─▶ PIPELINE B (Step 2B)
  │
  └─ 현재: feature/*
      ├─ --dev 또는 플래그 없음
      │   └─▶ PIPELINE A (Step 2A)
      │
      └─ --main
          ├─ 변경사항 없음 → checkout develop → PIPELINE B (Step 2B)
          └─ 변경사항 있음 → CHAIN MODE (Step 2A → Step 2B 자동 연결)

변경사항 없고 현재 브랜치 = develop이며 develop == main 이면 → 즉시 중단: "develop이 이미 main과 동일합니다."

1-3. 기능·보안·DB 사전검토

커밋 직전 기능 검증 게이트를 통과시킨 뒤 경량 보안/DB 검토를 수행한다.

1-3-0. 기능 검증 게이트 (verify.sh — 항상 우선 실행)

커밋·머지 전에 코드가 정적+단위 게이트를 통과하는지 확인한다. --no-verify 금지(아래 정책)의 상위 보증.

[ -f verify.sh ] && bash verify.sh --full

• --full: 커밋 전 시점이라 git diff 스코프가 좁을 수 있으므로 전체 검사로 vacuous-pass(아무것도 검사 안 하고 통과)를 방지한다.
• verify.sh 부재 시 → 조용히 통과시키지 않는다. 프로젝트에 통합 검증 스크립트가 없다는 뜻이므로:
  1. 프로젝트에 관례적 검증 명령이 있으면(package.json의 test/build/lint, Makefile의 test 등) 그걸 실행한다.
  2. 그것도 없으면 REPORT 상단에 "⚠️ 기능 게이트 없음 — 미검증 코드 ship" 경고를 크게 표시하고, 네이티브 /verify(앱 실행·동작 확인)·/security-review(변경 diff 보안 검토)로 최소 확인을 권한다.
  3. 사용자가 명시적으로 진행을 승인하지 않는 한, 완전 미검증 상태로 protected 브랜치 머지까지 자동 진행하지 않는다.
• FAIL → 즉시 중단, 사용자에게 실패 항목 보고. tsc/lint/build/단위테스트 미통과 코드는 ship하지 않는다.
• 이미 구현·리팩토링 파이프라인을 거쳐 통과 상태라면 빠르게 재확인되어 통과한다 — /ship 직접 진입 시의 최소 기능 안전망.

변경 파일 목록 추출 (보안/DB 검토용):

git diff --name-only HEAD

1-3-1. 보안 검토 (항상 실행)

security-auditor 에이전트(이 플러그인에 동봉)를 QUICK 모드로 호출한다.

• 전달: 변경된 코드 파일 목록 (.ts, .tsx, .js, .jsx, .py, .go, .sql)
• Critical 발견 시 → 사용자에게 보고 후 수정 여부 확인
• Warning/Info만 → 계속 진행 (REPORT에 포함)
• 코드 파일 없으면 건너뜀

• security-auditor 에이전트가 설치돼 있지 않은 환경이면 네이티브 /security-review(변경 diff 보안 검토)로 대체하고, 그것도 없으면 REPORT에 "보안 검토 미실행" 경고를 남긴다.

1-3-2. DB 스키마 검토 (migration 파일 변경 시에만)

git diff --name-only HEAD | grep -E "(\.sql$|migration|schema\.(ts|js|prisma)|drizzle|prisma/migrations|supabase/migrations)"

• 패턴 매칭 없음 → 건너뜀
• 패턴 매칭 있음 → db-schema-reviewer 에이전트(이 플러그인에 동봉) QUICK 모드 호출
  • Critical 발견 시 → 사용자에게 보고 후 수정 여부 확인
  • Warning/Info만 → 계속 진행

  • db-schema-reviewer 에이전트가 없는 환경이면 REPORT에 "DB 스키마 검토 미실행 — 마이그레이션 수동 검토 권장" 경고를 남기고 계속 진행한다.

보안/DB 검토는 QUICK 모드: 커밋 직전 머지 전 최소 안전망. 이미 별도 보안/리뷰 단계를 거쳤다면 중복이 되지만 가볍게 통과된다. (기능 게이트 1-3-0은 QUICK이 아닌 전체 verify.sh다 — 머지 전 기능 보증의 핵심.)

Step 2L — GitHub Flow MODE (develop 없음)

feature/* → main 단일 흐름으로 수행한다.

현재 브랜치가 feature/ 가 아니면(main/master 등에서 바로 ship 시도) 작업용 feature 브랜치를 생성한다:*

CUR=$(git branch --show-current)
# feature/* 이면 그대로 사용. 아니면 커밋 메시지에서 파생한 슬러그로 새 브랜치 생성.
#   슬러그 = 커밋 메시지 첫 줄을 kebab-case로 (예: "add login" → feature/add-login)
#   메시지 자동생성 전이라 파생 불가하면 feature/work 사용
git checkout -b feature/<슬러그>

• main/master에서 직접 커밋하지 않기 위한 안전장치다. 절대 protected 브랜치에 직접 push하지 않는다.

• 이미 feature/* 브랜치면 이 단계를 건너뛴다.

• 변경사항 없으면 중단

• 민감 파일 체크 → git add -A → git commit -m "{메시지}" → git push -u origin {브랜치}

• PR 생성: head={feature 브랜치}, base=main

• PR 머지 (squash 기본)

• git checkout main && git pull origin main

• git fetch --prune

• git checkout {feature 브랜치} && git rebase main

Step 2A — PIPELINE A (feature → develop)

민감 파일 체크

git status --short 결과에 .env, credentials, secrets 등 포함 시 → 즉시 중단.

Commit & Push

git add -A
git commit -m "{커밋 메시지}"
git push -u origin {feature 브랜치}

PR 생성 및 머지

gh pr create 또는 MCP GitHub 도구 사용 (gotchas 참조):

• head: 현재 feature 브랜치
• base: develop
• title: 커밋 메시지 첫 줄
• body:

  ## Summary
  {변경 파일 목록 및 작업 요약}
  
  ## Branch
  `{feature 브랜치}` → `develop`
  

• merge_method: squash (기본) / --merge / --rebase 옵션 반영

머지 후 동기화

git checkout develop && git pull origin develop
git checkout {feature 브랜치} && git rebase develop

Step 2B — PIPELINE B (develop → main)

develop 최신화

git checkout develop
git pull origin develop

PR 생성 및 머지

• head: develop
• base: main
• title: 커밋 메시지 첫 줄 (체인 모드에서는 "release: {원본 메시지}")
• body:

  ## Summary
  {변경 파일 목록 및 작업 요약}
  
  ## Branch
  `develop` → `main`
  

• merge_method: squash (기본) / --merge / --rebase 옵션 반영

머지 후 동기화

git checkout main && git pull origin main
git checkout develop && git rebase main
git push origin develop    # develop도 main 기준으로 최신화

Step 3 — 결과 보고

GitHub Flow MODE / PIPELINE A 단독

✅ Ship 완료
──────────────────────────────────────
PR:      #{번호} (merged → {develop | main})
커밋:    {메시지}
현재:    {브랜치명} ({타겟 브랜치} 동기화 완료)
──────────────────────────────────────

PIPELINE B 단독

✅ Ship 완료
──────────────────────────────────────
PR:      #{번호} (merged → main)
커밋:    {메시지}
현재:    develop (main 동기화 완료)
──────────────────────────────────────

CHAIN MODE (A → B)

✅ Ship 완료 (체인 모드)
──────────────────────────────────────
PR #{번호}:   {feature 브랜치} → develop (merged)
PR #{번호+1}: develop → main (merged)
커밋:         {메시지}
현재:         {feature 브랜치} (develop 동기화 완료)
──────────────────────────────────────

주의사항

• merge 실패 시 (충돌 등) 즉시 중단하고 원인 보고. 강제 머지 시도 금지.
• --no-verify 절대 사용 금지
• 체인 모드에서 Pipeline A 실패 시 Pipeline B 실행하지 않음
• 체인 모드에서 Pipeline A 완료 후 Pipeline B 실패 시: "feature→develop은 완료. git checkout develop && /ship --main으로 재시도하세요." 안내