---
name: commit-push
version: 1.2.0
description: 변경 사항을 커밋하거나 원격에 푸시한다. "커밋해줘", "푸시해줘", "커밋하고 푸시", "올려줘" 요청 시 사용하며 명시된 푸시는 재확인 없이 수행한다.
---

# commit-push

## 목적

현재 변경 내용을 분석하여 Conventional Commits 형식의 한국어 설명 커밋 메시지를 작성하고, 사용자가 요청한 커밋 또는 푸시를 수행한다.
일반적인 커밋/푸시는 승인 질문 없이 진행하고, 실제 위험 신호가 있을 때만 사용자 확인을 받는다.

## 언제 호출할지

- "커밋해줘", "커밋하고 푸시해줘" 요청 시
- "변경 사항 올려줘", "푸시해줘" 요청 시
- 코드 작업 완료 후 "반영해줘", "올려줘" 요청 시

## 입력

- `scope`: 커밋 범위 — all(전체) 또는 특정 파일/경로 (선택, 기본값: all)
- `push`: 푸시 여부 (선택, 기본값: auto)
  - auto: 요청에 "푸시", "push", "올려줘", "반영해줘", "커밋하고 푸시"가 있으면 true, "커밋만" 또는 "푸시하지 마"가 있으면 false
  - true: 푸시 여부를 다시 묻지 않고 현재 브랜치를 원격에 푸시한다
  - false: 커밋만 수행하고 푸시는 생략한다

## 먼저 확인할 것

- [ ] 커밋할 변경 사항 또는 push할 unpushed commit이 존재하는가 (`git status`로 확인)
- [ ] 현재 브랜치, 원격, upstream 상태가 일반 커밋/푸시에 적합한가
- [ ] `.env`, 시크릿 파일 등 민감한 파일이 스테이징에 포함되어 있지 않은가

## 실행 절차

1. **변경 사항 파악**
   - `git status`로 변경/추가/삭제된 파일 목록을 확인한다
   - `git diff`로 구체적인 변경 내용을 확인한다
   - 커밋할 변경 사항이 없고 push가 true이며 unpushed commit이 있으면 커밋 단계는 건너뛰고 푸시를 진행한다
   - 커밋할 변경 사항도 없고 push할 unpushed commit도 없으면 사용자에게 알리고 종료한다

2. **민감 파일 검사**
   - 스테이징 대상에 아래 패턴이 포함되면 해당 파일을 제외하고 사용자에게 경고한다
     - `.env`, `.env.*`
     - `*secret*`, `*credential*`, `*password*`
     - `*.pem`, `*.key`, `*.p12`
   - `.gitignore`에 이미 등록된 파일은 무시한다

3. **커밋 메시지 작성**
   - 변경 내용을 분석하여 Conventional Commits 형식으로 커밋 메시지를 작성한다
   - 아래 메시지 규칙을 따른다

4. **위험 신호 판단**
   - 아래 위험 신호가 없으면 사용자 승인 없이 다음 단계로 진행한다
   - 위험 신호가 있으면 커밋/푸시를 멈추고 대상 파일, 커밋 메시지, 위험 내용을 짧게 보여준 뒤 사용자 확인을 받는다
     - 민감 파일 패턴이 스테이징 대상에 포함됨
     - 사용자가 지정한 scope 밖의 변경을 포함해야 함
     - 현재 브랜치가 사용자 요청이나 작업 맥락과 다를 가능성이 큼
     - merge/rebase 충돌, detached HEAD, git 작업 중 상태가 감지됨
     - 원격이 diverged 상태거나 일반 push가 실패해 force push가 필요해 보임
   - 사용자가 메시지 수정을 요청하면 반영한다

5. **커밋 실행**
   - 커밋할 변경 사항이 없고 push할 unpushed commit만 있으면 이 단계를 건너뛴다
   - scope에 따라 파일을 스테이징한다
     - all: 변경된 전체 파일을 개별적으로 `git add`
     - 특정 경로: 해당 파일만 `git add`
   - 작성한 메시지로 `git commit`을 실행한다

6. **푸시 실행**
   - push가 true인 경우에만 실행한다
   - 사용자가 푸시를 명시했으면 푸시 여부를 다시 묻지 않는다
   - 현재 브랜치를 원격에 푸시한다
   - 원격 브랜치가 없으면 `-u origin {branch}`로 설정한다
   - 일반 push가 실패하거나 충돌이 발생하면 사용자에게 알리고 중단한다
   - `--force`가 필요해 보여도 자동 실행하지 않고 사용자 확인을 받는다

7. **결과 보고**
   - 커밋 해시, 메시지, 변경 파일 수, 푸시 결과를 출력한다

## 커밋 메시지 규칙

### 형식

```
<type>(<scope>): <한국어 서술형 요약>

<왜 변경했는지 설명하는 한국어 본문> (선택)

<footer> (선택)
```

`scope`는 선택 사항이며 변경 영역을 짧은 ASCII 토큰으로 쓴다. 예: `agent-ops`, `sync`, `docs`, `api`

### type 목록

| type | 용도 |
|------|------|
| feat | 새로운 기능 추가 |
| fix | 버그 수정 |
| docs | 문서 추가/수정 |
| refactor | 동작 변화 없는 구조 개선 |
| test | 테스트 추가/수정 |
| chore | 잡무성 변경, 저장소 관리 |
| build | 빌드, 패키징, 의존성 변경 |
| ci | CI/CD 설정 변경 |
| perf | 성능 개선 |
| revert | 이전 커밋 되돌림 |

### 작성 원칙

- `type`과 `scope`는 Conventional Commits 호환을 위해 영어 ASCII 토큰을 사용한다
- 요약과 본문은 **한국어**로 작성한다
- 요약은 50자 이내로 간결하게 작성한다
- 요약은 "~한다" 형태의 서술형으로 끝낸다 (예: "로그인 검증 로직을 추가한다")
- 본문은 **무엇을** 변경했는지가 아니라 **왜** 변경했는지를 쓴다
- 변경 파일이 3개 이하이면 본문을 생략할 수 있다
- 여러 성격의 변경이 섞여 있으면 가장 핵심적인 변경을 기준으로 타입을 정한다
- 이슈, PR, 작업 ID가 있으면 footer에 `Refs: #123`, `Closes: #123`처럼 남긴다
- breaking change는 `type(scope)!:` 또는 footer의 `BREAKING CHANGE:`로 표시한다

### 예시

```text
docs(commit-push): 푸시 승인 조건을 명시한다
```

```text
fix(sync): unpushed commit 푸시 흐름을 보강한다

작업 트리에 변경이 없어도 로컬 커밋이 원격보다 앞서 있으면
커밋 단계를 건너뛰고 푸시해야 한다.
```

## 출력 형식

```
## 커밋 완료

- 브랜치: {브랜치명}
- 커밋: {해시} — {커밋 메시지 요약}
- 변경 파일: {n}개
  - {파일 경로}: {변경 유형}
- 푸시: {성공/생략/실패}
```

## 실행 결과 검증

- [ ] `git log -1`로 방금 생성한 커밋이 존재하고, 메시지가 작성한 내용과 일치하는가
- [ ] 커밋에 포함된 파일 목록이 의도한 scope와 일치하는가 (`git diff-tree --no-commit-id --name-only -r HEAD`)
- [ ] push가 true인 경우, `git status`에서 "Your branch is up to date" 또는 원격과 동기화 상태인가
- 검증 실패 시: 실패 원인(커밋 누락, 푸시 실패 등)을 사용자에게 알리고 재시도 여부를 확인한다

## 금지 사항

- `git add -A` 또는 `git add .`을 사용하지 않는다 (민감 파일 혼입 방지)
- `git push --force`를 사용하지 않는다
- 명시적인 커밋/푸시 요청이 있고 위험 신호가 없는데도 습관적으로 사용자 승인을 요구하지 않는다
- 위험 신호를 무시하고 커밋하거나 푸시하지 않는다
- `type`과 `scope`를 제외한 요약/본문을 영어로 작성하지 않는다
- 변경 내용과 무관한 커밋 메시지를 작성하지 않는다
- `--no-verify` 옵션을 사용하지 않는다
