;

git push 전에 실수를 막는 no-mistakes 사용 방법 본문

Programing

git push 전에 실수를 막는 no-mistakes 사용 방법

WindowsHyun 2026. 7. 8. 23:34
반응형

개요

본 포스트는 git push 전에 실수를 막는 no-mistakes 설치와 기본 사용 과정을 설명합니다.
로컬 저장소 앞에 검증 게이트를 두고, 통과한 변경만 실제 remote와 PR 단계로 넘기는 흐름입니다.
AI 코딩 도구를 자주 쓰거나, push 직전에 테스트와 린트를 자주 놓치는 저장소라면 바로 써볼 만합니다.

전체 구성 흐름

로컬 브랜치: 평소처럼 수정하고 commit 하는 작업 구간입니다.
gate remote: git push no-mistakes를 받는 로컬 Git 프록시입니다.
disposable worktree: 원본 작업 폴더와 분리된 임시 검증 공간입니다.
finding 처리: 안전한 수정은 자동 반영하고, 의도 판단이 필요한 변경은 멈춘 뒤 사용자 승인을 받습니다.
PR 생성: 모든 검사가 끝난 뒤 실제 push target으로 넘기고 PR을 엽니다.

실제 remote 대신 gate remote로 먼저 보냅니다. 이 한 단계만 지켜도 main 브랜치 오염이나 급한 push 실수를 크게 줄입니다.
빌드 후 배포 자동화는 젠킨스(Jenkins) 윈도우(Windows) 버전 빌드 후 FTP로 파일 전송 방법 글과 같이 묶어서 보시면 됩니다.

적용 대상

  • GitHub PR 흐름이 있는 개인 저장소
  • 소규모 팀 저장소
  • AI 코딩 결과를 push 전에 한 번 더 걸러야 하는 저장소
  • 로컬에서 빠르게 테스트하고, 통과한 변경만 remote로 넘기려는 경우
  • 이미 서버 CI 규칙이 강하고, PR 없이 바로 배포되는 저장소는 우선순위가 낮습니다.

사전 준비 사항

  • Git이 설치된 macOS, Linux, Windows 환경
  • GitHub push 권한이 있는 저장소
  • 에이전트 검증을 붙일 경우 사용 중인 CLI 로그인 상태
  • 예시 경로와 remote 주소는 실제 값 대신 <작업_경로>, git@github.com:<USER>/<REPO>.git 형태로 적어두는 편이 안전합니다.

설치 절차

1.1. 설치 스크립트 실행

공식 설치 스크립트는 아래처럼 실행합니다.

curl -fsSL https://raw.githubusercontent.com/kunchenguid/no-mistakes/main/docs/install.sh | sh

설치가 끝나면 버전 확인을 해주시면 됩니다.

no-mistakes --help

1.2. 저장소 초기화

작업 저장소로 이동한 뒤 gate remote를 만듭니다.

cd <작업_경로>
no-mistakes init

정상이라면 gate no-mistakes와 실제 remote 정보가 함께 출력됩니다.
기존 origin은 그대로 두고, 검증용 no-mistakes만 추가됩니다.

1.3. gate remote로 push

이제부터는 바로 origin으로 보내지 않고 아래 명령을 먼저 씁니다.

git push no-mistakes <브랜치명>

이 명령은 검증 워크트리에서 리뷰, 테스트, 문서, 린트, PR 준비 흐름을 돌립니다.
중간에 멈춘 finding이 있으면 no-mistakes TUI에서 확인하시면 됩니다.

no-mistakes

저장소 성격상 자동 수정이 부담되면 finding을 보고 직접 고친 뒤 다시 gate remote로 보내주시면 됩니다.

1.4. 에이전트 작업에 붙이기

README 기준으로 /no-mistakes 스킬도 같이 설치됩니다.
이미 commit 된 변경을 다시 검증하거나, 에이전트가 고친 내용을 같은 게이트에 태우는 흐름에 잘 맞습니다.

  • 사람이 먼저 수정: git push no-mistakes <브랜치명>
  • 에이전트가 수정 후 검증: /no-mistakes <작업>
  • 기존 commit 재검증: /no-mistakes

이 구조는 로컬 우선이라서 사내 VPN, 사설 테스트 DB, <서버_IP> 같은 내부 점검 흐름과도 맞물립니다.
다만 production 비밀값은 작업 트리와 별도 secret 저장소에 두셔야 합니다.

주요 오류 및 해결 방안

제 경우 원인은 remote 이름을 바꾸지 않고 origin에 바로 push하던 습관이었습니다.
이 상태에서는 no-mistakes를 설치해도 게이트를 거치지 않으니, 브랜치 보호 규칙이 약한 저장소라면 실수가 바로 올라갑니다.

  • 증상: git push origin <브랜치명>은 바로 올라가고 PR 검증이 비어 있습니다.
  • 원인: gate remote 대신 기존 remote를 계속 사용한 상태입니다.
  • 해결: 평소 push 명령을 git push no-mistakes <브랜치명>으로 바꾸고, shell alias나 Git alias로 굳혀두면 재발이 줄어듭니다.

설치 직후 no-mistakes init이 실패한다면 저장소 쓰기 권한이나 Git remote 상태부터 보는 편이 낫습니다.
이미 no-mistakes remote가 남아 있으면 이름 충돌일 가능성이 높습니다.

확인

cd <작업_경로>
git remote -v

no-mistakes remote와 기존 origin이 같이 보이면 정상입니다.

git push no-mistakes <브랜치명>

파이프라인 시작 로그가 나오고, 모든 검사가 끝난 뒤 PR 생성 단계로 넘어가면 정상적으로 설치된 것입니다.

no-mistakes

TUI에서 finding 목록과 처리 상태가 보이면 정상적으로 연결된 것입니다.

반응형
Comments