공동 작업실을 하나 빌렸다고 해봅니다. 문에 번호키가 달려 있습니다. 아무리 친한 사이라도 비밀번호를 알려주기 전까지는 문 앞에서 돌아갑니다. 나쁜 뜻이 아니라 그냥 문이 안 열립니다.

들어온 다음은 다른 이야기입니다. 벽에 화이트보드가 하나 있고, 거기에 할 일을 적어둡니다. "선반 조립하기", "전구 갈기". 누가 어느 걸 맡았는지 적어두면 같은 일을 둘이 하지 않습니다.

오늘 배우는 게 딱 이 둘입니다. 문을 열어주는 것(협업자 초대)과 화이트보드(Issue) 입니다.

지금까지 스물네 강 동안 한 일은 전부 혼자였습니다. 가지를 만든 것도 나, 합친 것도 나, 24강에서 결재를 올리고 도장을 찍은 것도 나였습니다. 오늘은 사람을 한 명 부릅니다. 옆자리와 짝을 지으면 됩니다.

1. 서로를 협업자로 초대한다문 비밀번호를 알려주는 단계
2. 짝의 저장소를 clone 한다17강에서 한 그대로
3. 가지를 만들어 한 줄 고치고 push21 · 24강에서 한 그대로
4. 남의 저장소에 PR 을 올린다오늘 처음 하는 일
5. 짝이 보고 합친다내가 아닌 사람이 도장을 찍는다

16강의 403 을 다시 꺼냅니다

16강에서 403 의 세 갈래 원인을 봤습니다. 그중 두 번째가 로그인은 제대로 됐는데도 막히는 경우였습니다.

• $ git push origin master
• remote: Permission to 짝의계정/study-repo.git denied to 내계정.
• fatal: unable to access 'https://github.com/짝의계정/study-repo.git/': The requested URL returned error: 403
• # 아이디는 분명 내 것이 맞다. 그런데도 막힌다

그때 "너 이 창고 열쇠 없어" 라는 뜻이라고 했고, 해결은 25강에서 본다고 미뤄뒀습니다. 오늘이 그날입니다. 답은 간단합니다. 주인이 열쇠를 주면 됩니다.

서로를 협업자로 초대합니다

여기부터 브라우저입니다. 짝과 나 둘 다 자기 저장소에서 해야 하니 한 번씩 두 번 일어납니다.

1. 01

   내 저장소 화면 위쪽 Settings 를 누릅니다

   저장소 설정입니다. 계정 설정이 아닙니다. 주소에 저장소 이름이 들어 있는지 확인합니다

2. 02

   왼쪽 목록에서 Collaborators → Add people

   협업자라는 뜻입니다. 누르면 비밀번호를 한 번 더 물어볼 수 있습니다

3. 03

   짝의 깃허브 아이디를 칩니다

   이름이 아니라 아이디입니다. 짝의 프로필 주소 github.com/ 뒤에 붙은 그 글자입니다. 비슷한 아이디가 많으니 프로필 사진까지 보고 고릅니다

4. 04

   Add to repository 로 확정합니다

   목록에 짝이 Pending invite 로 뜹니다. 비밀번호는 알려줬고 아직 문을 안 연 상태입니다

5. 05

   받은 쪽은 가입할 때 쓴 메일함을 엽니다

   invited you to collaborate 메일이 와 있습니다. 안 보이면 깃허브 오른쪽 위 종 모양 알림에도 있습니다

6. 06

   Accept invitation 을 누릅니다

   이제 짝의 저장소를 열면 위쪽에 Settings 탭이 보입니다. 남의 저장소인데 설정 탭이 보이면 권한이 생긴 겁니다

짝의 저장소를 받아옵니다

이제 터미널입니다. 17강에서 학원과 집 두 대로 했던 clone 을 다시 씁니다. 다른 점은 주소가 남의 것이라는 것뿐입니다.

• $ git clone https://github.com/짝의계정/study-repo.git
• Cloning into 'study-repo'...
• Receiving objects: 100% (24/24), done.
• $ cd study-repo
• $ git log --oneline
• 5f2c1a9 소개 문단 추가
• 8b4d012 README 로 이름 바꿈
• a91c73e 첫 커밋

내가 안 쓴 커밋들이 보입니다. 짝이 5강부터 쌓아온 기록입니다. 여기에 오늘 내 커밋을 하나 얹습니다.

이제 컴퓨터에 폴더가 둘이 됐습니다. 내 my-first-repo 와 짝의 study-repo 입니다. 어느 폴더에서 명령을 치고 있는지 늘 확인합니다. 헷갈리면 git remote -v 를 칩니다. 지금 이 폴더가 어느 깃허브 주소와 연결돼 있는지 나옵니다.

남의 저장소에 PR 을 올립니다

24강에서 한 것과 완전히 같습니다. 순서를 그대로 밟습니다.

1. 01

   가지를 만듭니다

   남의 저장소일수록 알아보게 짓습니다

   git switch -c add-my-name

2. 02

   README.md 를 열어 한 줄 더합니다

   ## 함께한 사람 같은 제목을 만들고 그 아래에 자기 이름을 적습니다. 12강에서 배운 목록 문법을 씁니다

3. 03

   담고 커밋합니다

   git add README.md
   git commit -m "함께한 사람에 이름 추가"

4. 04

   가지를 올립니다

   여기서 403 이 안 나면 초대가 제대로 된 겁니다. 나면 수락이 빠진 것이니 위로 돌아갑니다

   git push -u origin add-my-name

5. 05

   터미널에 찍힌 주소로 PR 을 엽니다

   24강에서 본 그 remote: 안내 줄입니다. 제목과 설명을 적고 Create pull request

여기서 24강과 결정적으로 달라지는 게 하나 있습니다. 합치는 버튼을 내가 안 누릅니다.

24강 — 내 저장소

• 내가 올리고 내가 합쳤습니다
• 볼 사람이 없어 그냥 눌렀습니다
• 설명을 대충 써도 티가 안 났습니다
• 결재를 올리고 내가 도장을 찍었습니다

오늘 — 짝의 저장소

• 내가 올리고 짝이 합칩니다
• 짝이 Files changed 를 보고 판단합니다
• 설명이 부실하면 바로 물어봅니다
• 이게 실무에서 매일 일어나는 모양입니다

짝은 자기 저장소의 Pull requests 탭에서 새 PR 을 봅니다. Files changed 로 뭐가 바뀌는지 확인하고, 궁금하면 그 줄에 댓글을 답니다. 괜찮으면 Merge pull request 를 누릅니다. 남이 내 이름을 자기 저장소에 넣어준 겁니다. 이게 오늘의 결과물입니다.

화이트보드 — Issue

문 여는 이야기는 끝났고, 이제 화이트보드입니다.

일하다 보면 "고쳐야 할 것"과 "고친 것"이 따로 놉니다. PR 은 이미 고친 것을 올리는 자리입니다. 아직 안 고친 것, 고쳐야겠다고 생각만 한 것은 어디에 적을까요. 그게 Issue 입니다.

	Issue	Pull Request
언제 쓰나	하기 전	하고 나서
내용	"이거 고쳐야 합니다"	"이렇게 고쳤습니다"
파일 변경	없음 — 글만	있음 — 파일이 바뀜
끝내는 법	Close 로 닫는다	Merge 로 합친다
비유	화이트보드의 할 일	다 하고 올리는 결재

1. 01

   짝의 저장소에서 Issues → New issue

   Pull requests 바로 왼쪽 탭입니다

2. 02

   제목을 한 줄로 적습니다

   10강에서 커밋 메시지를 두고 한 이야기 그대로입니다. "수정" 말고 뭘 해야 하는지 적습니다

3. 03

   본문에 상황을 적습니다

   여기도 마크다운이 먹습니다. 체크박스 - [ ] 를 쓰면 화면에 진짜 네모칸이 나오고 눌러서 체크됩니다. 12강에서 배운 게 여기서 값을 합니다

4. 04

   Submit new issue 를 누릅니다

   #1 처럼 번호가 붙습니다. 이 번호를 다음 단계에서 씁니다

Issue 를 보고 작업을 끝냈으면, 그 PR 설명 칸에 closes #1 이라고 한 줄 적습니다. PR 이 합쳐지는 순간 1번 Issue 에 닫힘 표시가 붙습니다. 할 일과 한 일이 연결되는 겁니다. 나중에 그 Issue 를 열어보면 "이 문제는 저 PR 로 해결됐다" 는 링크가 남아 있습니다.

숫자 앞에 # 만 붙이면 어디서든 링크가 됩니다. 커밋 메시지에 git commit -m "소개 문단 추가 (#1)" 라고 적어도 나중에 그 커밋에서 Issue 로 바로 넘어갑니다.

둘이서 같은 저장소를 쓸 때

혼자 할 때는 안 겪던 일이 생깁니다. 내가 모르는 사이에 저장소가 바뀝니다. 짝이 아침에 PR 을 합쳤는데 나는 그걸 모르고 계속 작업했다면, push 할 때 이런 게 뜹니다.

• $ git push origin master
• ! [rejected] master -> master (fetch first)
• error: failed to push some refs to 'https://github.com/짝의계정/study-repo.git'
• hint: Updates were rejected because the remote contains work that you do
• hint: not have locally.
• $ git pull origin master
• Fast-forward
• $ git push origin master

16강에서 배운 대로 error: 로 시작하는 줄만 봅니다. contains work that you do not have locally — "여기 네가 안 가진 게 있다" 입니다. 권한 문제가 아니라 순서 문제라서, pull 하고 다시 push 하면 풀립니다. 겹치는 줄을 고쳤다면 23강의 충돌이 나고, 그건 이미 풀어봤습니다.

17강에서 "앉으면 pull" 이라고 한 습관이 둘이 되는 순간 필수가 됩니다.

정리하면

• 깃허브 저장소는 읽기는 누구나, 쓰기는 주인만 입니다. 그래서 남의 저장소에 push 하면 403 이 납니다
• 열어주는 방법이 협업자 초대입니다. Settings → Collaborators → Add people
• 초대만으로는 안 됩니다. 받은 쪽이 수락해야 열립니다. 여기서 제일 많이 막힙니다
• 남의 저장소도 순서는 똑같습니다. clone → 가지 → 커밋 → push → PR
• 다른 점은 하나입니다. 합치는 버튼을 내가 안 누릅니다. 그래서 PR 설명을 잘 써야 합니다
• Issue 는 하기 전, PR 은 하고 나서입니다. Issue 는 글만 있고 파일이 안 바뀝니다
• PR 설명에 closes #1 을 적으면 합쳐질 때 그 Issue 가 자동으로 닫힙니다
• Issue 본문에도 마크다운이 먹습니다. 체크박스가 특히 쓸모 있습니다
• 둘이 쓰면 rejected ... fetch first 를 만납니다. 권한이 아니라 순서 문제라 pull 하면 풀립니다
• 초대는 저장소 하나 단위고, 주는 권한은 전부입니다. 아무에게나 하지 않습니다
• 오늘 이후 19강에서 만든 프로필에 남과 함께한 이력이 처음으로 붙습니다

이제 스물다섯 강을 왔습니다. 혼자 기록하는 것부터 시작해서 깃허브에 올리고, 웹페이지를 띄우고, 가지를 치고, 남과 주고받는 데까지 왔습니다.

마지막 26강은 성격이 좀 다릅니다. 새 개념을 배우는 게 아니라 일하다 보면 반드시 만나는 상황 네 가지를 미리 겪어둡니다. 하던 작업을 급하게 치워둬야 할 때, 9강에서 감췄던 그 파일을 실수로 올려버렸을 때, 커밋을 잘못했다는 걸 뒤늦게 알았을 때, 그리고 오늘 마지막에 던져둔 것 — 초대받을 수 없는 남의 프로젝트에 기여하는 방법입니다. 구급상자를 하나 챙겨두는 강이라고 보면 됩니다.