학습 자료

푸시가 거부될 때 ② 남의 계정이 붙어 있습니다


Article

PC방에 가서 자리에 앉습니다. 브라우저를 켰더니 앞사람 메신저가 로그인된 채로 남아 있습니다. 앞사람이 로그아웃을 안 하고 그냥 나간 겁니다.

이 상태에서 내 아이디와 비밀번호를 아무리 정확히 쳐도 소용없습니다. 로그인 창이 아예 안 뜨니까요. 컴퓨터는 이미 로그인된 사람이 있다고 생각합니다. 먼저 할 일은 내 비밀번호를 다시 확인하는 게 아니라 앞사람을 로그아웃시키는 것입니다.

오늘 다룰 게 정확히 이 상황입니다. 15강에서 토큰을 제대로 발급받았는데도 push 가 거부되는 사람들이 있습니다. 학원이나 회사 공용 컴퓨터라면 열에 아홉이 이것 때문입니다.

에러 메시지부터 읽을 줄 알아야 합니다

이 강의에서 제일 중요한 건 사실 자격 증명 관리자가 아닙니다. 영어 에러를 읽는 법입니다. 이거 하나만 되면 앞으로 막혔을 때 혼자 빠져나올 수 있습니다.

push 가 실패하면 영어가 서너 줄 쏟아집니다. 전부 읽을 필요가 없습니다. 줄마다 말하는 주체가 다릅니다.

에러의 각 줄은 누가 하는 말인가
줄 머리누가 하는 말어떻게 대하나
remote:깃허브 서버가 하는 말여기만 읽는다. 진짜 이유가 여기 있다
fatal:내 컴퓨터의 깃이 포기했다는 말결과 통보다. 이유는 없다
hint: · 링크 줄일반적인 안내문지금은 넘어간다
remote 는 '원격', 즉 저쪽 서버를 뜻한다. 저쪽이 하는 말이 원인이고 나머지는 그 결과다

영어 네 줄이 무섭지, remote: 한 줄은 대개 짧습니다. 그 줄만 사전 찾아가며 읽으면 됩니다. 그래서 화면을 위에서부터 읽지 않습니다. remote: 를 눈으로 먼저 찾습니다. 그 줄이 아예 없이 fatal: 만 나왔다면 서버까지 가지도 못했다는 뜻이라, 인터넷이 끊겼거나 주소가 틀린 경우입니다.

한 줄에 이름이 두 개 나옵니다

가장 흔한 거부 메시지가 이겁니다.

Git Bash
  • $ 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방 화면에 남아 있던 그 계정이다
403 은 '너 이 창고 열쇠 없어' 라는 뜻이다. 문제는 그 '너' 가 누구냐다

두 이름을 확인하면 원인이 갈립니다. 여기서부터 세 갈래입니다.

원인 판정
  1. push 가 거부됐다remote: 줄을 찾는다
  2. denied to 뒤가 내 아이디가 아니다→ 원인 ① 남의 자격 증명이 남아 있다
  3. denied to 뒤는 내 아이디인데 Permission to 뒤가 남의 것→ 원인 ② 정말로 권한이 없다
  4. push 는 되는데 잔디가 안 심긴다→ 원인 ③ 메일 주소가 다르다
증상은 셋 다 비슷한데 고치는 자리가 전부 다르다

원인 ① 앞사람 자격 증명이 남아 있습니다

15강 끝에서 말했습니다. 한 번 성공하면 윈도우가 토큰을 저장해 두고 다음부터는 안 묻는다고요. 편한 기능인데, 저장된 게 내 것이 아니면 그대로 문제가 됩니다. 깃은 저장된 걸 조용히 꺼내 쓰고, 조용히 거부당합니다. 나한테는 아무것도 안 물어봅니다.

저장해 두는 곳이 윈도우의 자격 증명 관리자입니다. 여기서 옛 기록을 지우면, 다음 push 때 깃이 다시 물어봅니다. 앞사람을 로그아웃시키는 것과 같습니다.

자격 증명 관리자에서 깃허브 기록 지우기
  1. 01

    시작 버튼을 누르고 자격 증명 관리자 라고 칩니다

    제어판을 헤매는 것보다 검색이 빠릅니다. 영문 윈도우라면 Credential Manager 입니다

  2. 02

    `Windows 자격 증명` 을 고릅니다

    위에 웹 자격 증명 이 먼저 보이는데 그쪽이 아닙니다. 브라우저에 저장된 비밀번호라 상관없습니다

  3. 03

    목록에서 git:https://github.com 을 찾습니다

    목록이 길면 스크롤해서 찾습니다. git: 으로 시작하는 줄입니다

  4. 04

    그 줄을 눌러 펼치고 제거를 누릅니다

    확인 창이 뜨면 예를 누릅니다. 지워도 깃허브 계정에는 아무 일도 안 생깁니다

  5. 05

    터미널로 돌아와 git push 를 다시 칩니다

    git push
  6. 06

    이번에는 아이디와 토큰을 다시 묻습니다

    물어보면 성공입니다. 15강처럼 아이디와 토큰을 넣습니다

지우는 건 이 컴퓨터에 저장된 로그인 기록뿐이다. 저장소도 커밋도 그대로다

원인 ② 정말로 권한이 없습니다

denied to 뒤가 분명히 내 아이디인데도 403 이 납니다. 이건 다른 문제입니다. 로그인은 제대로 됐고, 그 창고에 들어갈 자격이 없는 것입니다.

남의 저장소에 push 하려 할 때 이렇게 됩니다. 강사가 만든 저장소 주소를 그대로 받아 적었거나, 인터넷에서 본 저장소를 따라 하다가 그렇게 되는 경우가 많습니다. 깃허브에서 아무 저장소나 남이 고치게 두지 않는 것은 당연한 일입니다.

내가 어디로 보내려 하는지부터 봅니다
  1. 01

    git remote -v 를 칩니다

    git remote -v
  2. 02

    주소에 적힌 아이디를 봅니다

    github.com/여기/저장소이름.git여기 가 내 아이디여야 합니다

  3. 03

    남의 아이디라면 주소를 잘못 적은 것입니다

    14강에서 git remote add 할 때 남의 주소를 넣은 겁니다

14강에서 등록해 둔 창고 주소를 다시 확인하는 것이다

주소가 남의 것이었다면 내 저장소를 하나 만들어 그 주소로 바꾸면 됩니다. 그런데 정말로 남의 저장소에 보태고 싶은 경우도 있습니다. 팀 저장소가 그렇습니다. 그때는 방법이 둘입니다.

남의 저장소에 참여하는 두 갈래

협업자로 초대받기

열쇠를 하나 더 만들어 받는 것

  • 저장소 주인이 나를 등록해 준다
  • 그때부터 그 저장소에 바로 push 할 수 있다
  • 팀으로 일할 때 쓰는 방식이다
  • 25강에서 직접 해봅니다

복사해서 내 것으로 만들기

창고 내용물을 통째로 복사해 내 칸에 두는 것

  • 주인 허락 없이 혼자 할 수 있다
  • 내 저장소가 되니 push 가 된다
  • 남의 공개 프로젝트에 참여할 때 쓴다
  • fork 라고 부릅니다. 26강에서 다룹니다
지금은 이런 게 있다는 것만 알아두면 된다. 오늘 할 일은 아니다

원인 ③ 커밋은 되는데 잔디가 안 심깁니다

세 번째는 성격이 조금 다릅니다. push 는 잘 됩니다. 깃허브에 파일도 올라가 있습니다. 그런데 프로필의 초록색 잔디가 안 심깁니다. 커밋 목록에 내 사진이 아니라 회색 사람 모양이 뜨기도 합니다.

인증 문제가 아닙니다. 커밋에 적힌 메일 주소가 깃허브 계정 메일과 다른 것입니다.

2강에서 user.nameuser.email 을 설정했습니다. 택배 송장에 보내는 사람을 적는 일이었습니다. 깃허브는 커밋이 도착하면 그 송장의 메일 주소를 보고 "이 사람이 누구지" 하고 계정을 찾습니다. 등록된 메일이 아니면 누구인지 몰라서 잔디를 못 심습니다.

메일 주소 맞추기
  1. 01

    지금 뭐라고 적혀 있는지 봅니다

    git config --global user.email
  2. 02

    깃허브 계정 메일과 같은지 비교합니다

    깃허브 SettingsEmails 에서 확인합니다

  3. 03

    다르면 다시 설정합니다

    git config --global user.email "깃허브에_등록된_메일"
  4. 04

    새로 커밋을 하나 만들어 push 해봅니다

    이번 커밋부터 잔디가 심깁니다

2강에서 한 것과 똑같은 명령이다. 값만 고쳐 다시 치면 덮어쓴다

한 가지만 덧붙입니다. 잔디를 채우려고 의미 없는 커밋을 매일 하나씩 만드는 사람이 있는데, 채용하는 쪽에서는 커밋을 눌러보면 다 보입니다. 잔디는 결과지 목표가 아닙니다. 10강에서 커밋 메시지를 왜 그렇게 신경 써서 썼는지 생각해 보면 답이 나옵니다. 지금은 안 심기는 원인만 고치고 넘어갑니다.

셋을 한 장으로

증상 → 원인 → 고칠 자리
증상원인어디를 고치나
denied to 뒤가 남의 아이디앞사람 자격 증명이 저장돼 있다자격 증명 관리자에서 git:https://github.com 제거
denied to 뒤는 나, 주소가 남의 것그 저장소 권한이 없다git remote -v 로 주소 확인 · 초대 · fork
push 는 되는데 잔디가 안 심긴다커밋 메일이 계정 메일과 다르다git config --global user.email
고칠 자리가 셋 다 다르다. 그래서 remote 줄을 읽는 게 먼저다

여기까지 오면 인증으로 막히는 일은 대부분 혼자 풀 수 있습니다. 안 되면 마지막 수단이 하나 더 있습니다. 자격 증명을 지우고, 토큰을 새로 발급받고, 다시 넣는 것입니다. 오늘 배운 것과 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 을 구분해서 다룹니다.

푸시가 거부될 때 ② 남의 계정이 붙어 있습니다 — 디코드랩(DCODELAB)