GitHub Push Attribution란｜author·committer·pusher 차이와 확인 방법
GitHub Push Attribution은 커밋을 push할 때 인증된 사용자를 커밋별로 기록하는 기능입니다. 커밋 안에 적힌 author·committer 정보와 구분해 실제 push에 사용된 계정을 확인하도록 돕습니다. GitHub는 2026년 10월 12일 이 기능을 발표했으며, 10월 13일 확인 기준 GitHub Enterprise 고객 대상의 제한 공개 프리뷰입니다.
먼저 알아둘 점
- 이름·이메일로 표시된 커밋 정보와 인증 계정은 다른 정보입니다.
- 새 규칙은 committer 이메일을 인증된 pusher의 검증된 이메일과 대조합니다.
- 프리뷰 참여는 GitHub 담당 account team에 접근을 요청하는 방식입니다.
author·committer·pusher는 무엇이 다른가요?
| 구분 | 의미 | 확인하는 정보 |
|---|---|---|
| author | 변경 내용을 처음 작성한 사람 | 커밋에 기록된 이름·이메일 |
| committer | 변경을 적용해 해당 커밋을 만든 사람 | 커밋에 기록된 이름·이메일 |
| pusher | GitHub에 push할 때 인증된 사용자 | GitHub가 확인한 push 인증 주체 |
Git에서 author와 committer는 서로 다를 수 있습니다. 예를 들어 개발자 A가 만든 패치를 개발자 B가 적용하면 A는 author, B는 committer로 기록될 수 있습니다. B가 이를 자신의 계정으로 push하는 상황이라면 pusher도 B가 됩니다.
위 예시는 역할 차이를 설명하기 위한 가상 상황입니다. 실제 조사에서는 이름이 같다는 이유만으로 세 역할을 동일인으로 판단하지 말고, 커밋 메타데이터와 인증 기록을 따로 확인하세요.
Git의 이름·이메일 설정은 인증 비밀번호나 토큰이 아닙니다. user.name과 user.email은 커밋에 들어갈 정보를 정하며, push 인증은 별도로 이뤄집니다.
용어 근거: Git 공식 문서: 커밋 이력 확인, Git 설정 문서
커밋 정보 확인 방법: 로컬 Git과 GitHub를 구분
로컬에서는 author와 committer를 먼저 확인하세요
저장소 폴더의 터미널에서 아래 명령을 실행하면 최근 커밋 5개의 작성자·커미터와 날짜를 확인할 수 있습니다. 커밋이나 설정을 변경하는 명령이 아닙니다.
git log -5 --format=fuller출력의 Author와 Commit 항목을 비교하세요. 이 명령은 GitHub가 기록한 pusher 조회 명령이 아닙니다. 로컬 커밋 메타데이터만으로 원격 push 인증 주체를 확정하지 마세요.
GitHub에서는 프리뷰 제공 여부를 먼저 확인하세요
공식 발표는 pusher 정보를 UI와 API에 제공한다고 설명합니다. 대상 저장소의 커밋 화면에서 표시 여부를 확인하되, 정확한 화면 배치와 API 스키마는 프리뷰 안내를 따르세요. 과거 커밋의 소급 적용 범위도 이 발표만으로 단정할 수 없습니다.
조사를 시작할 때는 저장소와 커밋 SHA를 함께 기록하면 서로 다른 커밋을 비교하는 혼선을 줄일 수 있습니다. 표시된 정보가 없으면 미확인으로 남기고 조직 관리자에게 프리뷰 적용 여부를 문의하세요.
명령어 근거: Git log 공식 문서
Committer must match pusher 규칙은 무엇을 검사하나요?
새 규칙 Committer must match pusher는 committer 메타데이터의 이메일이 인증된 pusher의 검증된 이메일 중 하나와 일치하지 않으면 push를 차단합니다. author와 pusher가 같아야 한다는 조건으로 읽으면 안 됩니다.
기능의 역할을 나누면 pusher 기록은 추적에, 규칙은 불일치 차단에 활용됩니다. 기록이 보인다는 이유만으로 차단 규칙도 자동 적용됐다고 판단하지 말고 ruleset 설정을 확인하세요.
관리자가 확인할 설정 순서
- 프리뷰 접근 권한과 해당 규칙의 제공 여부를 확인합니다.
- 대상 저장소의 Settings → Rulesets에서 기존 규칙을 검토합니다.
- 제공되는 ruleset에 새 조건을 추가하고 적용 범위·활성 상태·bypass 권한을 확인합니다.
- 운영 저장소에 적용하기 전에 테스트 저장소에서 일반 개발과 자동화 흐름을 점검합니다.
Rulesets를 편집하려면 저장소 관리자 권한 또는 관련 편집 권한이 필요합니다. 일반 ruleset 메뉴가 보인다는 사실만으로 이 프리뷰 규칙까지 사용할 수 있다는 뜻은 아닙니다.
근거: Push Attribution 공식 발표, GitHub Rulesets 생성 안내
push 경로를 점검할 때는 API 키가 커밋에 포함되는 문제도 함께 확인할 수 있습니다. 유출 경고 대응은 아래 글에서 별도로 살펴보세요.
도입 전 점검사항과 API 확인 범위
다음은 운영 적용을 위한 점검 제안입니다. 자동화와 협업 방식을 먼저 확인하면 정상적인 작업이 예상치 못하게 차단되는 상황을 줄일 수 있습니다.
- 개발자 환경: 저장소별 커밋 이메일과 실제 push 인증 계정이 의도한 조합인지 확인합니다.
- 패치·cherry-pick: 작성자와 커미터가 달라지는 작업을 테스트합니다.
- 자동화: CI·봇이 사용하는 인증 방식과 커미터 정보의 처리 조건을 프리뷰 담당자에게 확인합니다.
- 예외 권한: bypass 대상과 승인 기준을 문서화합니다.
- 조사 기록: 커밋 SHA, 관련 PR, 인증 주체와 확인 시점을 함께 남깁니다.
API 연동은 필드와 권한부터 확인하세요
실제 연동 전에는 적용되는 REST·GraphQL 지원 범위, 응답 필드, 필요한 권한과 데이터 누락 조건을 확인해야 합니다. 공식 발표에 구체적인 호출 경로와 필드명이 제시되지 않았으므로, 기존 API 응답의 임의 필드를 새 기능과 동일시하지 마세요.
사내 감사 시스템에는 “확인됨·미확인·해당 없음”을 구분해 저장하는 방식을 검토할 수 있습니다. 필드가 비어 있다는 이유만으로 해당 커밋을 비정상으로 분류하지 않도록 설계하세요.
인증된 계정 기록이 있더라도 그 계정의 자격증명을 실제로 누가 사용했는지는 추가 조사가 필요할 수 있습니다. 계정 공유·토큰 관리·접근 권한 점검을 함께 운영하세요.
IDE에서 사용하는 계정과 조직 정책을 점검하려면 Copilot JetBrains 관련 설정도 함께 확인할 수 있습니다.
자주 묻는 질문
author와 committer가 다르면 위조 커밋인가요?
그렇지 않습니다. 패치를 다른 사람이 적용하는 등 정상적인 협업에서도 다를 수 있습니다. 불일치 자체보다 작업 경위와 관련 PR·인증 기록을 함께 확인해야 합니다.
git user.email을 바꾸면 push 계정도 바뀌나요?
아닙니다. 커밋 이메일 설정과 원격 인증 자격증명은 별개입니다. 회사·개인 계정을 함께 사용한다면 저장소 설정과 인증 방식을 각각 확인하세요.
커밋의 Verified 서명 표시와 같은 기능인가요?
확인하는 대상이 다릅니다. 커밋 서명 검증은 서명에 관한 확인이며, push 인증 주체의 기록과 구분해야 합니다. 서명 요구 정책과 push 관련 정책을 각각 검토하세요.
개인 저장소나 Enterprise Server에서도 바로 쓸 수 있나요?
발표된 범위를 넘어 지원을 가정하지 마세요. 개인 요금제와 Enterprise Server의 버전별 적용 여부는 별도 안내를 확인해야 합니다.
공식 자료
- GitHub: Push attribution for commits in limited public preview
- Git: author·committer와 커밋 이력
- GitHub: 저장소 Rulesets 생성
- GitHub: 커밋 서명 검증
