푸시가 거부될 때 ② 남의 계정이 붙어 있습니다
Article
PC방에 가서 자리에 앉습니다. 브라우저를 켰더니 앞사람 메신저가 로그인된 채로 남아 있습니다. 앞사람이 로그아웃을 안 하고 그냥 나간 겁니다.
이 상태에서 내 아이디와 비밀번호를 아무리 정확히 쳐도 소용없습니다. 로그인 창이 아예 안 뜨니까요. 컴퓨터는 이미 로그인된 사람이 있다고 생각합니다. 먼저 할 일은 내 비밀번호를 다시 확인하는 게 아니라 앞사람을 로그아웃시키는 것입니다.
오늘 다룰 게 정확히 이 상황입니다. 15강에서 토큰을 제대로 발급받았는데도 push 가 거부되는 사람들이 있습니다. 학원이나 회사 공용 컴퓨터라면 열에 아홉이 이것 때문입니다.
에러 메시지부터 읽을 줄 알아야 합니다
이 강의에서 제일 중요한 건 사실 자격 증명 관리자가 아닙니다. 영어 에러를 읽는 법입니다. 이거 하나만 되면 앞으로 막혔을 때 혼자 빠져나올 수 있습니다.
push 가 실패하면 영어가 서너 줄 쏟아집니다. 전부 읽을 필요가 없습니다. 줄마다 말하는 주체가 다릅니다.
| 줄 머리 | 누가 하는 말 | 어떻게 대하나 |
|---|---|---|
remote: | 깃허브 서버가 하는 말 | 여기만 읽는다. 진짜 이유가 여기 있다 |
fatal: | 내 컴퓨터의 깃이 포기했다는 말 | 결과 통보다. 이유는 없다 |
hint: · 링크 줄 | 일반적인 안내문 | 지금은 넘어간다 |
영어 네 줄이 무섭지, remote: 한 줄은 대개 짧습니다. 그 줄만 사전 찾아가며 읽으면 됩니다. 그래서 화면을 위에서부터 읽지 않습니다. remote: 를 눈으로 먼저 찾습니다. 그 줄이 아예 없이 fatal: 만 나왔다면 서버까지 가지도 못했다는 뜻이라, 인터넷이 끊겼거나 주소가 틀린 경우입니다.
한 줄에 이름이 두 개 나옵니다
가장 흔한 거부 메시지가 이겁니다.
- $ git push -u origin master
- remote: Permission to 내계정/my-first-repo.git denied to 앞사람계정.
- fatal: unable to access 'https://github.com/내계정/my-first-repo.git/': The requested URL returned error: 403
remote: 줄 하나에 아이디가 두 개 들어 있습니다. 이걸 갈라 읽는 게 오늘의 핵심입니다.
Permission to A denied to B 를 나눠 읽기A — Permission to 뒤
들어가려는 창고의 주인
- 지금 push 하려는 저장소가 누구 것인지
- 내 저장소면 여기가 내 아이디여야 한다
- 여기가 남의 아이디라면 주소를 잘못 적은 것이다
B — denied to 뒤
지금 이 컴퓨터에 붙어 있는 사람
- 깃이 저장해 둔 자격 증명의 주인
- 여기가 내 아이디가 아니면 앞사람이 로그인돼 있는 것이다
- PC방 화면에 남아 있던 그 계정이다
두 이름을 확인하면 원인이 갈립니다. 여기서부터 세 갈래입니다.
- push 가 거부됐다
remote:줄을 찾는다 denied to뒤가 내 아이디가 아니다→ 원인 ① 남의 자격 증명이 남아 있다denied to뒤는 내 아이디인데Permission to뒤가 남의 것→ 원인 ② 정말로 권한이 없다- push 는 되는데 잔디가 안 심긴다→ 원인 ③ 메일 주소가 다르다
원인 ① 앞사람 자격 증명이 남아 있습니다
15강 끝에서 말했습니다. 한 번 성공하면 윈도우가 토큰을 저장해 두고 다음부터는 안 묻는다고요. 편한 기능인데, 저장된 게 내 것이 아니면 그대로 문제가 됩니다. 깃은 저장된 걸 조용히 꺼내 쓰고, 조용히 거부당합니다. 나한테는 아무것도 안 물어봅니다.
저장해 두는 곳이 윈도우의 자격 증명 관리자입니다. 여기서 옛 기록을 지우면, 다음 push 때 깃이 다시 물어봅니다. 앞사람을 로그아웃시키는 것과 같습니다.
- 01
시작 버튼을 누르고
자격 증명 관리자라고 칩니다제어판을 헤매는 것보다 검색이 빠릅니다. 영문 윈도우라면
Credential Manager입니다 - 02
`Windows 자격 증명` 을 고릅니다
위에
웹 자격 증명이 먼저 보이는데 그쪽이 아닙니다. 브라우저에 저장된 비밀번호라 상관없습니다 - 03
목록에서
git:https://github.com을 찾습니다목록이 길면 스크롤해서 찾습니다.
git:으로 시작하는 줄입니다 - 04
그 줄을 눌러 펼치고 제거를 누릅니다
확인 창이 뜨면 예를 누릅니다. 지워도 깃허브 계정에는 아무 일도 안 생깁니다
- 05
터미널로 돌아와
git push를 다시 칩니다git push - 06
이번에는 아이디와 토큰을 다시 묻습니다
물어보면 성공입니다. 15강처럼 아이디와 토큰을 넣습니다
원인 ② 정말로 권한이 없습니다
denied to 뒤가 분명히 내 아이디인데도 403 이 납니다. 이건 다른 문제입니다. 로그인은 제대로 됐고, 그 창고에 들어갈 자격이 없는 것입니다.
남의 저장소에 push 하려 할 때 이렇게 됩니다. 강사가 만든 저장소 주소를 그대로 받아 적었거나, 인터넷에서 본 저장소를 따라 하다가 그렇게 되는 경우가 많습니다. 깃허브에서 아무 저장소나 남이 고치게 두지 않는 것은 당연한 일입니다.
- 01
git remote -v를 칩니다git remote -v - 02
주소에 적힌 아이디를 봅니다
github.com/여기/저장소이름.git의여기가 내 아이디여야 합니다 - 03
남의 아이디라면 주소를 잘못 적은 것입니다
14강에서
git remote add할 때 남의 주소를 넣은 겁니다
주소가 남의 것이었다면 내 저장소를 하나 만들어 그 주소로 바꾸면 됩니다. 그런데 정말로 남의 저장소에 보태고 싶은 경우도 있습니다. 팀 저장소가 그렇습니다. 그때는 방법이 둘입니다.
협업자로 초대받기
열쇠를 하나 더 만들어 받는 것
- 저장소 주인이 나를 등록해 준다
- 그때부터 그 저장소에 바로 push 할 수 있다
- 팀으로 일할 때 쓰는 방식이다
- 25강에서 직접 해봅니다
복사해서 내 것으로 만들기
창고 내용물을 통째로 복사해 내 칸에 두는 것
- 주인 허락 없이 혼자 할 수 있다
- 내 저장소가 되니 push 가 된다
- 남의 공개 프로젝트에 참여할 때 쓴다
- fork 라고 부릅니다. 26강에서 다룹니다
원인 ③ 커밋은 되는데 잔디가 안 심깁니다
세 번째는 성격이 조금 다릅니다. push 는 잘 됩니다. 깃허브에 파일도 올라가 있습니다. 그런데 프로필의 초록색 잔디가 안 심깁니다. 커밋 목록에 내 사진이 아니라 회색 사람 모양이 뜨기도 합니다.
인증 문제가 아닙니다. 커밋에 적힌 메일 주소가 깃허브 계정 메일과 다른 것입니다.
2강에서 user.name 과 user.email 을 설정했습니다. 택배 송장에 보내는 사람을 적는 일이었습니다. 깃허브는 커밋이 도착하면 그 송장의 메일 주소를 보고 "이 사람이 누구지" 하고 계정을 찾습니다. 등록된 메일이 아니면 누구인지 몰라서 잔디를 못 심습니다.
- 01
지금 뭐라고 적혀 있는지 봅니다
git config --global user.email - 02
깃허브 계정 메일과 같은지 비교합니다
깃허브
Settings→Emails에서 확인합니다 - 03
다르면 다시 설정합니다
git config --global user.email "깃허브에_등록된_메일" - 04
새로 커밋을 하나 만들어 push 해봅니다
이번 커밋부터 잔디가 심깁니다
한 가지만 덧붙입니다. 잔디를 채우려고 의미 없는 커밋을 매일 하나씩 만드는 사람이 있는데, 채용하는 쪽에서는 커밋을 눌러보면 다 보입니다. 잔디는 결과지 목표가 아닙니다. 10강에서 커밋 메시지를 왜 그렇게 신경 써서 썼는지 생각해 보면 답이 나옵니다. 지금은 안 심기는 원인만 고치고 넘어갑니다.
셋을 한 장으로
| 증상 | 원인 | 어디를 고치나 |
|---|---|---|
denied to 뒤가 남의 아이디 | 앞사람 자격 증명이 저장돼 있다 | 자격 증명 관리자에서 git:https://github.com 제거 |
denied to 뒤는 나, 주소가 남의 것 | 그 저장소 권한이 없다 | git remote -v 로 주소 확인 · 초대 · fork |
| push 는 되는데 잔디가 안 심긴다 | 커밋 메일이 계정 메일과 다르다 | git config --global user.email |
여기까지 오면 인증으로 막히는 일은 대부분 혼자 풀 수 있습니다. 안 되면 마지막 수단이 하나 더 있습니다. 자격 증명을 지우고, 토큰을 새로 발급받고, 다시 넣는 것입니다. 오늘 배운 것과 15강을 순서대로 하면 됩니다.
학원 공용 컴퓨터를 쓴다면 습관 하나를 권합니다. 나갈 때 자격 증명 관리자에서 내 기록을 지우는 것입니다. 다음 사람이 오늘 겪은 일을 안 겪고, 무엇보다 내 토큰이 남의 손에 남지 않습니다. 15강에서 토큰은 비밀번호라고 했습니다. 공용 컴퓨터에 두고 나올 물건이 아닙니다.
정리하면
- 영어 에러는 전부 읽지 않습니다.
remote:로 시작하는 줄만 봅니다. 그게 깃허브가 하는 말입니다 fatal:은 깃이 포기했다는 결과 통보일 뿐이라 이유가 없습니다Permission to A denied to B는 이름이 두 개입니다. A 는 창고 주인, B 는 지금 붙어 있는 사람입니다- B 가 내 아이디가 아니면 앞사람 자격 증명이 남은 것입니다 — 자격 증명 관리자에서
git:https://github.com을 제거합니다 - 지우면 다음 push 때 다시 물어봅니다. 그때 아이디와 토큰을 넣습니다
- 브라우저에서 로그아웃해도 소용없습니다. 터미널과 브라우저는 저장하는 곳이 다릅니다
- B 가 내 아이디인데도 403 이면 그 저장소 권한이 없는 것입니다 —
git remote -v로 주소부터 확인합니다 - 남의 저장소에 참여하는 길은 둘입니다. 초대받기(25강) 와 fork(26강) 입니다
- push 는 되는데 잔디가 안 심기면 인증 문제가 아닙니다.
user.email이 깃허브 계정 메일과 다른 것입니다 - 메일을 고쳐도 지난 커밋은 소급되지 않습니다. 반대로 그 메일을 계정에 추가 등록하는 방법이 있습니다
다음 17강은 반대 방향입니다. 지금까지는 내 컴퓨터에서 깃허브로 보내기만 했습니다. 이제 깃허브에 있는 것을 내려받습니다. 학원에서 작업하고 집에 와서 이어서 하려면 반드시 필요한 일입니다. 창고에 맡긴 물건을 찾아오는 것과 같습니다. 처음 통째로 받아오는 clone 과, 이미 받아둔 것에 새로 생긴 것만 받아오는 pull 을 구분해서 다룹니다.