jcchikikomori/skills-md

Git 규칙

• git commit 또는 git push를 절대 실행하지 마십시오. — 커밋은 GPG로 서명되기 때문입니다.
• 여러분의 임무는 변경 사항을 준비하고 스테이징하는 것(git add)입니다. 사용자는 자신의 터미널에서 GPG + TTY가 작동하는 환경에서 수동으로 커밋하고 푸시합니다.
• git stash, git diff, git status, git log, git add 등 읽기 전용 git 명령어는 모두 허용됩니다.
• 되돌리기/취소 작업의 경우 git blame을 사용하여 변경 사항을 식별하고 실수를 줄이십시오.
• 변경을 수행하기 전에 먼저 현재 리포지토리를 가져오십시오. 업스트림에서 진행 중인 변경 사항이 있으면 병합/리베이스가 필요한지 물어보십시오.

대상 브랜치에 병합 / 리베이스

업스트림 변경 사항을 통합하기 전에 다음 단계를 순서대로 실행하십시오:

1. 업스트림 가져오기

   git fetch origin
   

2. 분기점 확인 — 대상 브랜치에 있지만 현재 브랜치에는 없는 커밋

   git log HEAD..origin/<target> --oneline
   

3. 겹치는 파일 변경 사항 확인

   git diff --name-only HEAD...origin/<target>
   

4. 사양/테스트 영향 확인 실행 (아래 참조) — 병합 또는 리베이스 전에 반드시 수행하십시오.

5. 충돌 위험 평가 — 분기점이나 파일 겹침이 심각할 경우 사용자에게 병합할지 리베이스할지 물어보십시오.

6. 스테이지만 수행 — 사용자가 수동으로 커밋하고 푸시합니다(GPG 제약 조건).

사양 및 테스트 영향 확인

병합이나 리베이스 전에 현재 브랜치 작업과 겹치는 업스트림 사양/테스트 변경 사항을 검색하십시오:

git diff HEAD...origin/<target> -- \
  '*_spec.rb' '*.spec.*' '*.test.*' \
  'spec/' 'test/' '__tests__/' 'tests/'

업스트림에서 사양/테스트 파일이 변경된 경우:

• diff 표시 — 변경된 테스트 파일과 변경 내용을 보여주십시오.
• 도메인 중복 플래그 지정 — 변경된 테스트가 현재 브랜치에서 수정하는 동일한 기능이나 파일을 다루는지 식별하십시오.
• 진행 전에 물어보십시오 — 현재 브랜치 구현이 오래되었거나 새로 변경된 사양에 의해 테스트될 가능성이 있는 경우, 사용자에게 먼저 브랜치를 업데이트할지 아니면 계속 진행할지 물어보십시오.

근거: 브랜치에 새 구현이 있는 상태에서 업스트림 테스트 변경 사항을 병합하면 CI에서 위음성(false-negative)이 발생합니다. 테스트가 이전 동작을 테스트하기 때문에 통과합니다. 병합 전에 사표 드리프트를 발견하면 혼란스러운 다운스트림 실패를 방지할 수 있습니다.

충돌 해결

• 병합 충돌이 있는 경우 문제를 평가하고 사용자에게 해결 여부를 결정하도록 요청하십시오.
• 각 파일별로 충돌을 해결하십시오. 한 번에 모든 것을 해결하지 마십시오.

태그

• 기존 버전 접두사(사용 가능한 경우)를 따르십시오.
• SemVer 버전 형식(예: v1.0.0-beta)을 따르십시오.

풀 리퀘스트 기준

• PR 크기 ≤ 200줄 (합리적인 단순화가 불가능한 경우는 예외).
• 제한된 범위: 티켓/스토리에 대한 변경 사항만 포함(관련 없는 리팩토링 금지).
• 짧은 설명 또는 변경 사항을 설명하는 점 목록 사용.