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	없음 (브랜치로 자동 결정)
머지 방식	--merge 또는 --rebase	squash
커밋 메시지	플래그 제외 나머지 문자열	변경사항 분석해 자동 생성

두 타겟 플래그 동시 입력 시 → 즉시 중단: "플래그는 --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 직접 진입 시의 최소 기능 안전망.