혼자 만드는 프로젝트에도 main 브랜치 보호를 거는 이유

사이드 프로젝트나 혼자 관리하는 저장소에서 브랜치 보호 규칙을 설정하는 사람은 많지 않다. "어차피 나 혼자인데" 싶어서다. 그런데 운영 중인 서비스가 연결된 저장소라면 얘기가 다르다.

직접 push가 위험한 순간

git push origin main을 실수로 날리는 경우는 생각보다 많다. 브랜치 이름을 착각했거나, 로컬 main에서 작업하다가 그대로 올린 경우다. 브랜치 보호가 없으면 이게 그냥 통과되고, CI가 돌기 전에 코드가 올라간다.

GitHub Actions로 배포 파이프라인을 연결해뒀다면 CI가 실패해도 이미 main에 커밋이 찍힌다. 롤백하려면 git revert나 force push가 필요해지고, 혼자라도 귀찮아진다.

GitHub 브랜치 보호 규칙 설정

저장소 Settings → Branches → Branch protection rules에서 main 패턴으로 규칙을 추가한다. 혼자 쓰는 저장소에서 최소한으로 걸어둘 만한 옵션은 두 가지다.

1. Require a pull request before merging 직접 push를 막고, PR을 통해서만 main에 병합하게 한다. 리뷰어를 지정하지 않아도 되고, 자기 자신의 PR을 자기가 머지하는 것도 허용된다. 핵심은 push 자체를 막는 것이다.

2. Require status checks to pass before merging CI가 통과한 커밋만 main에 들어오게 한다. GitHub Actions의 job 이름을 체크 목록에 추가해두면, CI 실패 상태에서 머지 버튼이 막힌다.

# .github/workflows/ci.yml
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test

Branch protection에서 test job을 required status check로 등록해두면 테스트가 통과한 커밋만 머지된다.

설정 후 달라지는 흐름

보호 규칙을 걸고 나면 작업 흐름이 이렇게 바뀐다.

1. main에서 직접 작업하지 않고 feat/xxx 브랜치를 판다
2. 작업 후 PR을 열면 CI가 돌고
3. 통과하면 머지한다

혼자 할 때는 PR 설명을 길게 쓸 필요 없다. 커밋 제목 정도만 써도 충분하고, 머지 기록이 남아서 나중에 언제 뭘 바꿨는지 추적하기가 쉬워진다.

예외: 긴급 수정이 필요할 때

브랜치 보호를 걸어두면 Allow force pushes나 Allow bypasses를 명시적으로 허용하지 않는 이상 직접 push가 안 된다. 급할 때는 일시적으로 규칙을 비활성화하거나, GitHub CLI로 관리자 권한으로 머지하는 방법이 있다.

# 관리자 권한으로 PR 머지 (브랜치 보호 우회)
gh pr merge <번호> --admin

평소엔 막아두고 정말 필요할 때만 푸는 구조가 낫다.