돌미나리

개발 공부를 시작하고 매일 1일 1커밋을 다짐하며 깃허브(GitHub) 프로필에 초록색 잔디를 채워나가는 재미를 붙이던 중이었습니다.

어느 날 평소처럼 터미널에서 코드를 수정하고 git add, git commit, git push를 마친 뒤 뿌듯한 마음으로 깃허브 프로필을 열었는데, 커밋 기록은 분명 원격 저장소에 올라가 있는데 프로필 잔디밭에는 초록불이 전혀 심어지지 않는 당혹스러운 상황을 마주쳤습니다.

처음에는 "깃허브 서버 반영이 늦나?" 싶어 몇 시간을 기다려보기도 하고, 컴퓨터를 껐다 켜보기도 했지만 잔디는 여전히 하얗게 비어 있었습니다.

오늘은 제가 깃허브 잔디 누락 문제로 멘붕을 겪으며 찾아낸 진짜 원인(로컬 Git 이메일 불일치)과, 5분 만에 깔끔하게 해결했던 설정 방법을 정리해 보려고 합니다.

1. 내가 마주친 문제: "커밋은 올라갔는데 왜 내 프로필에 반영이 안 될까?"

깃허브 저장소(Repository)의 Commits 탭에 들어가 보니, 제가 푸시한 커밋 내역 자체는 정상적으로 올라와 있었습니다.

하지만 커밋 작성자 프로필 사진이 제 깃허브 아바타가 아니라 기본 회색 실루엣 아이콘으로 떠 있었고, 작성자 이름을 클릭해도 제 깃허브 프로필 페이지로 링크가 연결되지 않았습니다.

💡 깃허브가 잔디를 심어주는 핵심 원리

깃허브는 푸시된 커밋의 작성자 이메일 주소(Author Email)를 보고 해당 계정의 잔디밭에 초록불을 심어줍니다.

• 내 컴퓨터(로컬)의 Git에 설정된 이메일 주소
• 실제 깃허브 계정에 등록된 이메일 주소

이 둘이 단 한 글자라도 다르면 깃허브는 "이 커밋은 다른 사람이 작성한 것"으로 인식하여 내 프로필 잔디를 채워주지 않는 것입니다.

2. 해결 단계 1: 내 로컬 Git 설정 이메일 확인하기

터미널을 열고 현재 내 컴퓨터의 Git 전역 설정(Global Config)에 어떤 이메일이 등록되어 있는지 확인해 보았습니다.

# 터미널에서 현재 설정된 Git 유저 이름과 이메일 확인 명령어
git config --global user.name
git config --global user.email

확인해 보니 예전에 임의로 입력했던 오타 섞인 이메일이나, 현재 깃허브 계정과는 다른 보조 이메일이 등록되어 있었습니다.

3. 해결 단계 2: 깃허브 실제 이메일과 일치시키기

원인을 알았으니 로컬 Git의 이메일을 깃허브 계정에 등록된 실제 이메일과 완벽하게 일치하도록 수정해 주었습니다.

# 1. 깃허브 계정 이메일과 동일하게 전역 설정 업데이트
git config --global user.name "내_깃허브_닉네임"
git config --global user.email "내_깃허브_가입이메일@example.com"

# 2. 변경된 내용이 잘 반영되었는지 확인
git config --global --list

💡 꿀팁: 깃허브 이메일 비공개(Keep my email address private) 설정 유저라면?

만약 깃허브 설정(Settings > Emails)에서 개인정보 보호를 위해 이메일 비공개 옵션을 켜두셨다면, 깃허브에서 발급해 주는 ID+username@users.noreply.github.com 형태의 노리플라이 이메일을 user.email에 등록하셔야 정상적으로 잔디가 심어집니다!

4. 해결 확인: 새 커밋 푸시 후 잔디밭 확인하기

설정을 올바르게 바꾼 뒤, 가볍게 README.md 파일을 수정하고 다시 커밋 및 푸시를 진행해 보았습니다.

git add README.md
git commit -m "docs: 깃 잔디 연동 테스트 커밋"
git push origin main

푸시 완료 후 깃허브 프로필 페이지를 새로고침하자마자, 비어 있던 칸에 선명한 초록색 잔디가 즉시 채워지는 것을 확인할 수 있었습니다! 커밋 내역의 프로필 아이콘도 제 프로필 사진으로 정상 연결되었습니다.

5. 깨달은 점 및 정리

처음에는 깃허브 시스템 오류인 줄 알고 헛걸음을 많이 했지만, Git의 사용자 식별 방식(이메일 기반 매칭)을 이해하고 나니 아주 단순하게 해결할 수 있었던 문제였습니다.

1. 커밋을 올렸는데 잔디가 안 심어진다면 가장 먼저 git config --global user.email 을 확인할 것!
2. 로컬 이메일과 깃허브 계정 이메일을 100% 일치시킬 것!

1일 1커밋을 실천 중인데 잔디가 심어지지 않아 스트레스받고 계신 분들이 계시다면, 지금 바로 터미널에서 이메일 설정부터 점검해 보시길 바랍니다!

프론트엔드 프로젝트를 진행하면서 코딩 자체보다 나를 더 식은땀 흘리게 만들었던 순간은 단연 'Git 명령어 실수'였습니다.

로직을 신나게 짜두고 커밋 하나 잘못 날려서 수시간 동안 작업했던 코드를 날려먹을 뻔하거나, Git Merge 충돌이 무서워서 소스 코드를 압축 파일로 복사해 두는 웃지 못할 삽질을 겪기도 했습니다.

오늘은 제가 프론트엔드 프로젝트를 진행하며 직접 겪었던 대표적인 Git 실수 3가지와, 이를 깔끔하게 해결했던 복구 명령어(Tip)를 정돈해 보려고 합니다.

1. 실수 1: 잘못된 브랜치에 코드를 다 짜놓았을 때 (git stash)

feature/login 브랜치에서 작업해야 하는데, 깜빡하고 main 브랜치나 다른 작업 브랜치에서 열심히 코드를 수정하고 있던 자신을 뒤늦게 발견했을 때입니다.

아직 커밋은 하지 않았는데 브랜치를 이동하자니 오류가 뜨고, 작업해 둔 코드가 날아갈까 봐 당황했던 기억이 있습니다.

💡 해결 방법: 임시 저장창고 git stash 활용하기

# 1. 현재 작업 중인 변경사항을 임시 저장소에 싹 감춰둡니다.
git stash

# 2. 올바른 작업 브랜치로 이동합니다.
git checkout feature/login

# 3. 임시 저장소에 있던 변경사항을 새로 이동한 브랜치에 꺼내옵니다.
git stash pop

이 3줄의 명령어만 알면 잘못된 브랜치에서 작성하던 코드를 안전하게 원하는 브랜치로 이사시킬 수 있습니다.

2. 실수 2: 커밋 메시지를 오타 내거나 파일을 빼먹고 커밋했을 때 (git commit --amend)

커밋을 날리자마자 커밋 메시지에 오타가 들어갔거나, 같이 올려야 하는 스타일 파일(CSS)을 빼먹고 커밋을 올렸다는 것을 깨달았을 때입니다. 새로운 커밋을 하나 더 만들자니 Git 히스토리가 지저분해져서 고민이었습니다.

💡 해결 방법: 직전 커밋 덮어쓰기 --amend

# 빼먹은 파일이 있다면 먼저 Stage에 올립니다.
git add src/styles/main.css

# 직전 커밋 메시지를 수정하거나 파일을 포함해 덮어씁니다.
git commit --amend -m "fix: 올바른 커밋 메시지 수정"

이미 날린 직전 커밋을 새 커밋으로 더럽히지 않고 깔끔하게 수정할 수 있습니다.

3. 실수 3: 코드 수정 중 전으로 돌리고 싶을 때 (git restore & git reset)

코드를 이것저것 고치다가 망해서 "아, 그냥 오늘 작업하기 전 상태로 싹 되돌리고 싶다" 할 때가 있습니다. 수동으로 Ctrl + Z를 수십 번 누르다가 코드가 엉키는 참사를 겪곤 했습니다.

💡 해결 방법: 상황별 되돌리기 명령어

• 아직 커밋하지 않은 파일의 변경사항 취소하기:
• Bash

   

  git restore src/App.tsx
  

• 직전 커밋을 취소하되 작성한 코드는 남겨두기 (Soft Reset):
• Bash

   

  git reset HEAD~1
  

• 지워진 커밋 찾아오기 (git reflog):
• 실수로 git reset --hard를 눌러서 커밋이 지워졌더라도 당황하지 마세요. Git은 모든 행동을 기록해 둡니다. git reflog를 치면 삭제된 커밋 ID를 찾아 원상복구할 수 있습니다!

4. 글을 마치며

Git은 단순히 소스 코드를 저장하는 구글 드라이브가 아니라, 개발자의 실수를 언제든 안전하게 과거로 되돌려주는 강력한 타임머신입니다.

명령어가 익숙지 않다고 두려워하기보다는, 직접 브랜치를 만들어보고 stash나 reset 명령어를 연습해 보면서 Git과 친해지시기를 추천합니다. 실수해도 복구하는 방법을 알면 개발이 훨씬 더 자신감 넘쳐집니다!