Commit Push Hd

feat/* 또는 hotfix/* 컨벤션에 매칭되더라도, 브랜치명이 현재 작업 내용을 정확히 반영하는지 검증한다.

1. git diff --name-only와 git diff --stat으로 변경된 파일과 내용을 파악한다.

2. 현재 브랜치명의 * 부분이 작업 내용을 대표하는지 판단한다:

   • feat/add-login-form인데 실제로는 다크모드를 작업 중 → 불일치
   • feat/dark-mode-toggle인데 실제로도 다크모드 작업 중 → 일치

3. 일치 → Step 1로 진행.

4. 불일치 → 사용자에게 알린다:

   "현재 브랜치명 feat/add-login-form이 실제 작업 내용(다크모드)과 맞지 않는 것 같습니다.

   1. 그대로 유지
   2. feat/dark-mode-toggle로 변경
   3. 직접 입력"

   사용자가 변경을 선택하면 git branch -m {새 이름}으로 변경 후 Step 1로 진행.

Step 0.2: 보호 브랜치 → 새 브랜치 생성

1. git diff의 변경 파일과 내용을 읽고 핵심 변경 내용을 2~4 단어로 요약한다.
2. 사용자에게 prefix를 질문한다:

   "현재 보호 브랜치({브랜치명})에 있습니다. 새 브랜치를 생성합니다. 브랜치 prefix를 선택해주세요:"

   1. feat — 기능 추가/변경
   2. hotfix — 긴급 버그 수정

3. kebab-case로 브랜치명을 생성하고 사용자에게 확인을 받는다:

   "브랜치명: feat/login-form-component — 이대로 생성할까요? (Y/수정)"

4. 브랜치를 생성한다:

   git checkout -b {브랜치명}
   

5. Step 1로 진행한다.

Step 0.3: 컨벤션 불일치 → 브랜치 이름 재생성

1. git diff의 변경 파일과 내용을 읽고 핵심 변경 내용을 2~4 단어로 요약한다.
2. prefix를 질문하고 kebab-case 브랜치명을 생성한다.
3. 사용자에게 확인을 받는다:

   "현재 브랜치({현재 이름})가 컨벤션에 맞지 않습니다. feat/xxx로 변경할까요? (Y/수정)"

4. 브랜치 이름을 변경한다:

   git branch -m {새 브랜치명}
   

5. Step 1로 진행한다.

브랜치 이름 규칙

^(feat|hotfix)/[a-z][a-z0-9-]{1,40}$

Step 1: 커밋

/hyeondongs-harness:commit-hd 을 실행하여 변경사항을 논리적 단위별로 커밋한다.

Step 2: Push

git push -u origin {현재 브랜치}

push 실패 시 원인을 분석하고 유저에게 안내한다.