GitHub 커밋을 누가 push했는지 확인하는 법

세 줄 요약

author와 committer는 커밋에 기록된 정보이며, 실제 push 때 인증한 계정과 다를 수 있다.
지금 저장소를 조사하려면 Activity에서 관련 push와 변경 내용을 연결해 볼 수 있다.
새 push attribution은 Enterprise 제한 미리보기이며, committer 이메일 일치를 요구하는 규칙도 제공한다.

낯선 작성자 이름만으로 계정 침해를 판단할 수 없다

커밋 옆에 표시된 사람이 그 코드를 GitHub에 전송한 사람이라는 뜻은 아니다. GitHub는 커밋 헤더의 이메일을 계정 이메일과 연결해 사용자를 표시한다. 공식 문제 해결 문서는 커밋이 다른 사용자와 연결돼도 그 사용자에게 저장소 접근 권한이 생기는 것은 아니라고 설명한다.

author는 원래 작업한 사람, committer는 그 작업을 커밋으로 적용한 사람을 나타낸다. 다른 사람이 보낸 패치를 관리자가 적용하면 둘이 달라도 정상이다. Git 공식 책도 이 사례로 두 필드의 차이를 설명한다. pusher는 그 커밋을 서버에 올릴 때 인증한 계정이다.

정보	답할 수 있는 질문
Author	커밋에 누구를 원작자로 기록했는가?
Committer	누구를 이 변경의 적용자로 기록했는가?
Pusher	어느 계정으로 인증해 서버에 전송했는가?

자기 커밋이 잘못된 이름으로 보인다면 Git 이메일 설정과 계정에 등록한 이메일을 먼저 대조한다. 반대로 전송 행위 자체가 의심된다면 표시 이름을 고치는 일만으로 조사가 끝나지 않는다.

로컬 커밋 정보와 GitHub의 활동 기록을 나눠 확인한다

커밋에 어떤 이름이 기록돼 있는지는 다음 명령으로 읽을 수 있다. COMMIT_SHA는 확인할 커밋의 해시로 바꾼다.

git show COMMIT_SHA --pretty=fuller

여기서 Author와 Commit을 확인할 수 있다. Commit 줄을 실제 push 인증 계정으로 읽어서는 안 된다. 로컬 커밋 정보와 서버가 기록한 전송 행위를 연결해야 한다.

저장소의 Activity는 push·merge·force push·브랜치 변경을 커밋과 인증된 사용자에 연결한다. 파일 목록 오른쪽의 Activity를 열고 해당 브랜치와 기간으로 범위를 좁힌다. 활동 유형과 사용자 필터를 적용한 뒤 Compare changes에서 들어온 변경을 대조한다.

Activity는 사건을 찾는 출발점이다. 여러 저장소에 걸친 권한 변경이나 토큰 사용까지 이어진다면 조직·기업 감사 로그와 함께 봐야 한다. GitHub의 조사 도구 설명에 따르면 Activity는 저장소 읽기 권한으로 볼 수 있지만, 조직 감사 로그에는 조직 소유자 권한이 필요하다.

새 기능은 전송 계정을 커밋에 남기고, 선택적으로 불일치를 막는다

GitHub는 10월 12일 발표한 push attribution으로 인증된 pusher를 커밋별로 지속 기록하고 UI와 API에 표시한다. 2026년 10월 26일 기준 Enterprise 고객 대상 제한 공개 미리보기이며, 계정 담당자를 통한 접근 신청이 필요하다.

함께 제공하는 Committer must match pusher 규칙은 committer 정보가 전송 계정의 검증된 이메일 중 어느 것과도 맞지 않으면 push를 차단한다. 비교 대상은 author가 아니라 committer다. 작성자와 적용자가 다른 정상 협업까지 ‘이름이 다르다’는 이유로 같은 문제로 묶으면 안 된다.

표시된 이름을 알고 싶은지, 전송에 사용된 계정을 찾고 싶은지에 따라 볼 기록이 달라진다. 의심스러운 커밋의 해시를 정하고 Activity의 변경 내용과 연결하는 것이 조사 시작점이다.