IT 엘도라도 로고
IT 엘도라도
황금

Git 이미 푸시된 커밋들의 작성자(Author) 일괄 변경하기 (feat. GitHub 잔디 누락)

2021-05-13 21:29

Git 이미 푸시된 커밋들의 작성자(Author) 일괄 변경하기 (feat. GitHub 잔디 누락)

1. GitHub Contribution (feat. GitHub 잔디)

Git과 GitHub을 사용해본 개발자라면 분명 Git 저장소 생성 혹은 커밋 등의 기록이 GitHub Contribution이라는 형태로 GitHub에 기록되는 것을 본 적 있을 것이다. Contribution 개수에 따라 진한 정도가 조금씩 다르긴 하지만, 전반적으로 녹색으로 표시되기 때문에 흔히들 GitHub 잔디라고 부르곤 한다. 그리고 채용 시장에서는 GitHub 잔디가 무성할수록 성실하게 개발 공부에 임한 사람, 드문드문할수록 개발 공부에 게을렀던 사람으로 평가되기도 하는 것 같다(개인적으로 필자는 조금 다르게 생각하지만).
그런데 GitHub 잔디를 열심히 심고 싶은 사람들은 주의해야 할 점이 하나 있다. 바로 GitHub Contribution으로 기록되기 위한 조건이다. 즉, 커밋을 한다고 해서 무조건 잔디가 심어지는 것이 아니라, 해당 커밋이 특정한 조건을 만족해야 한다. 여러 가지 조건들이 존재하지만, 가장 놓치기 쉬운 하나의 조건을 언급하자면 다음과 같다.
"해당 커밋의 작성자(Author) 이메일이 GitHub 계정의 이메일과 동일해야 한다."
예를 들어, GitHub 계정의 이메일이 abc@gmail.com인데 작성자의 이메일이 def@naver.com으로 세팅되어 있는 상태라면, 이때 커밋하는 것들은 GitHub Contribution으로 기록되지 않는다. 즉, 아무리 열심히 커밋해도 잔디가 심어지지 않는다는 것이다. 이는 굉장히 놓치기 쉬우며, 실제로 많은 개발자들이 이러한 이유로 잔디가 누락되곤 한다. 같은 GitHub 저장소에 대해 개발 작업을 하더라도 개인 노트북, 회사 노트북 등과 같은 개발 환경에 따라 Git 세팅이 다를 수 있기 때문이다. 그러니 GitHub 잔디가 누락되지 않도록 하고 싶다면 작성자의 이메일이 GitHub 계정의 이메일과 동일하도록 미리 잘 세팅해둬야 할 것이다.
그러나 이미 푸시한 커밋들은 어떻게 할까? 작성자의 이메일을 다시 제대로 세팅했다면 앞으로의 커밋들은 문제가 없겠지만, 이미 GitHub에 푸시된 커밋들은 작성자의 이메일이 예전 것 그대로일 것이기 때문에 여전히 잔디로 표시되지 않는다. 이번 포스팅에서는 그러한 경우에 어떻게 해야 하는지 한 번 다뤄보도록 하자. (나의 잔디를 한 번 살려보자!)
 

2. 이미 푸시된 커밋들의 작성자(Author) 일괄 변경하기

문제 해결 방법을 소개하기에 앞서, 가장 기본적인 해결 원리는 다음과 같다. 바로 "작성자 이메일을 수정한 커밋들을 모조리 새로 만들고, 그것을 GitHub에 강제로 푸시하는 것"이다. 그런데 의문점이 하나 있다. 굳이 커밋들을 새로 만들어야 할까? 기존 커밋들의 작성자 이메일을 수정하는 방법은 없을까? 결론부터 얘기하자면 그것은 불가능하다. 커밋의 작성자 정보는 해당 커밋의 고윳값에 해당하는 해시 값을 결정하는 데 영향을 미치기 때문이다. 즉, 작성자를 바꾸면 커밋의 해시 값도 바뀌기 때문에 새로운 커밋이 만들어지는 것은 불가피하다.
그렇다면 본격적으로 해결 방법을 소개하도록 하겠다. 먼저, 쉘에서 문제를 해결하고자 하는 저장소의 경로에 찾아간 뒤, 다음 커맨드를 실행하여 작성자 이메일을 수정한 커밋들을 모조리 새로 만들도록 한다.
다음으로, 다음 커맨드를 실행하여 새로 만들어진 커밋들을 GitHub에 강제로 푸시한다.
끝이다. 이제 GitHub에 들어가서 해당 커밋들이 잔디로 잘 표시되는지 확인해보자. 원래는 표시되지 않던 잔디들이 이제는 표시된다면 성공한 것이다. (사실 위의 커맨드들을 자세히 설명하면 글이 길어지겠지만, 그렇게까지 중요한 내용은 아닌 듯하여 생략하였다.)
 

3. 위 방법을 사용할 때의 주의사항

그러나 위 해결 방법을 사용할 때는 매우 신중해야 한다. 기본적으로 강제 푸시(--force) 자체가 권장되는 기능이 아니다. 왜 그럴까? 그것은 바로 "강제 푸시가 원격 저장소에 존재하는 기존 커밋들을 모조리 날리기 때문"이다. 물론 해당 저장소가 개인적으로만 관리하는 것이라면 크게 문제가 안 될 것이다. 새로운 해시 값을 가진 커밋들로 모조리 교체하는 것이 뭐 그리 큰 문제가 되겠는가. 오히려 진짜 문제가 되는 상황은 바로 다음과 같은 경우이다.
"해당 저장소를 다른 사람과 함께 공유하여 사용(협업)하고 있는 경우"
강제 푸시로 인해 GitHub 저장소에 존재하는 기존 커밋들은 새로운 해시 값을 가진 커밋들에 의해 전부 덮어쓰기 처리된다. 이로 인해 해당 저장소를 가지고 개발 작업을 하던 다른 사람이 있었다면, 이후 그 사람은 해당 저장소에 대해 푸시를 하거나 풀을 할 때 에러를 마주치게 될 것이다. 그 사람의 로컬에 존재하는 커밋들과 전혀 싱크가 맞지 않기 때문이다. 따라서 강제 푸시를 했다면 반드시 해당 저장소를 함께 사용하고 있는 다른 사람에게 다음과 같은 사실을 인지시켜야만 한다.
"강제 푸시를 통해 저장소의 커밋들을 싹 다 바꿨으니, 새로 클론을 받은 뒤 작업해주세요."
알고 나면 그리 대단한 얘기도 아니긴 하지만, 모르고 있으면 굉장히 당황할 수 있는 문제라서 일부러 강조하여 설명하였다. 강제 푸시 기능을 사용하는 개발자분들은 이러한 주의사항을 늘 염두에 두기 바란다.
말풍선
댓글 0
좋아요 5
    아직 작성된 댓글이 없어요.
사용자