회사에서 비품을 하나 사야 한다고 해봅니다. 법인카드를 들고 그냥 나가서 긁는 회사는 없습니다. 먼저 종이 한 장을 올립니다. 뭘 왜 얼마에 사겠다고 적어서 내면, 위에서 보고 도장을 찍어줍니다. 그때 사러 갑니다.

번거로워 보이지만 이유가 있습니다. 첫째, 돈이 나가기 전에 한 번 걸러집니다. 둘째, 나중에 "이거 누가 왜 샀지" 싶을 때 그 종이가 남아 있습니다.

Pull Request 가 정확히 그 종이입니다. 내 가지를 master 에 넣기 전에 "이거 넣어도 될까요" 하고 올려두는 겁니다. 줄여서 PR 이라고 부릅니다.

21강에서 던져놓고 넘어간 질문이 있었습니다. "왜 master 에서 바로 안 짜는가." 오늘이 그 답입니다.

1. 가지에서 작업하고 커밋21강에서 한 그대로
2. 가지를 깃허브에 올린다지금까지는 master 만 올렸다
3. PR 을 연다"이거 넣어도 될까요"
4. 사람이 보고 답을 단다여기가 22강에는 없던 단계다
5. 괜찮으면 합친다깃허브 화면의 버튼으로

명령으로 합치는 것과 뭐가 다른가

22강에서 이미 합쳐봤습니다. git merge 한 줄이면 끝났습니다. 그런데 실무에서는 그 방식을 잘 안 씁니다.

git merge 로 바로

• 혼자 하는 연습에는 충분합니다
• 합쳐지고 나서야 남이 압니다
• 왜 그렇게 고쳤는지 기록이 없습니다
• 실수해도 걸러줄 사람이 없습니다

PR 로

• 합치기 전에 보여집니다
• 무엇이 어떻게 바뀌는지 화면에 나옵니다
• 왜 그랬는지 설명과 대화가 남습니다
• 괜찮다는 확인을 받고 합칩니다

세 번째 줄이 핵심입니다. 기록이 남습니다. 6개월 뒤에 "이 줄 왜 이렇게 돼 있지" 싶을 때, PR 을 열어보면 그때 오간 이야기가 그대로 있습니다. 10강에서 커밋 메시지를 두고 한 이야기의 확장판입니다.

가지를 만들고 작업합니다

늘 하던 대로입니다. 새로운 게 없습니다.

1. 01

   master 에 서 있는지 봅니다

   23강 끝에서 master 하나만 남아 있어야 합니다

   git branch

2. 02

   가지를 만듭니다

   22강에서 말한 대로 할 일 이름으로 짓습니다

   git switch -c add-intro

3. 03

   README.md 에 소개 한 줄을 더합니다

   ## 소개 아래에 자기 소개를 한 줄 적고 저장합니다. 12강에서 배운 마크다운 그대로 씁니다

4. 04

   담고 커밋합니다

   git add README.md
   git commit -m "소개 문단 추가"

가지를 깃허브로 올립니다

여기가 오늘의 첫 번째 새 명령입니다. 지금까지 push 는 늘 master 만 올렸습니다. 이번엔 가지를 올립니다.

• $ git push -u origin add-intro
• Enumerating objects: 5, done.
• Writing objects: 100% (3/3), 312 bytes | 312.00 KiB/s, done.
• remote: Create a pull request for 'add-intro' on GitHub by visiting:
• remote: https://github.com/내계정/my-first-repo/pull/new/add-intro
• To https://github.com/내계정/my-first-repo.git
• * [new branch] add-intro -> add-intro
• branch 'add-intro' set up to track 'origin/add-intro'.

* [new branch] — 창고에 새 가지가 하나 생겼습니다. 21강 끝에서 "만든 가지는 아직 깃허브에 없다" 고 한 것을 이제 올린 겁니다.

그 위 두 줄을 봅니다. 깃허브가 먼저 말을 겁니다. "이 가지로 PR 을 만들려면 여기로 오라" 며 주소까지 찍어줍니다. 16강에서 remote: 로 시작하는 줄만 보면 된다고 했는데, 그게 늘 에러만은 아닙니다. 이번엔 친절한 안내입니다.

저 주소를 그대로 복사해서 브라우저에 붙이면 PR 만드는 화면이 바로 열립니다.

-u 는 14강에서 git push -u origin master 를 칠 때도 붙였던 그것입니다. "이 가지는 앞으로 저기랑 짝" 이라고 등록해두는 뜻이라, 한 번 해두면 그다음부터는 이 가지에서 git push 만 쳐도 같은 곳으로 갑니다. 가지를 처음 올릴 때만 붙입니다.

PR 을 엽니다

여기부터는 브라우저입니다.

1. 01

   저장소 화면을 새로고침합니다

   방금 올린 가지 이름이 적힌 노란 띠가 위쪽에 나타나 있습니다

2. 02

   그 띠의 Compare & pull request 를 누릅니다

   안 보이면 Pull requests 탭 → New pull request 로도 갑니다

3. 03

   위쪽 화살표 두 개를 확인합니다

   base: master ← compare: add-intro 로 되어 있어야 합니다. 왼쪽이 받을 쪽, 오른쪽이 줄 쪽입니다. 22강에서 배운 그 방향입니다

4. 04

   제목과 설명을 적습니다

   제목은 커밋 메시지처럼 한 줄로. 설명 칸은 마크다운이 먹습니다 — 11~13강에서 배운 목록과 강조를 그대로 씁니다

5. 05

   아래로 내려 바뀐 내용을 봅니다

   7강에서 git diff 로 본 그 화면입니다. 더한 줄은 초록, 지운 줄은 빨강으로 나옵니다

6. 06

   Create pull request 를 누릅니다

   PR 이 하나 생기고 번호가 붙습니다. #1 부터 시작합니다

만들어진 PR 화면에는 탭이 몇 개 있습니다. 대화가 쌓이는 Conversation, 커밋 목록인 Commits, 바뀐 내용인 Files changed. 팀에서는 남이 Files changed 를 보면서 특정 줄에 댓글을 답니다. 줄 단위로 이야기가 가능합니다.

확인하고 합칩니다

지금은 혼자라 볼 사람이 없습니다. 그래서 내가 내 PR 을 봅니다. 어색하지만 실무에서도 자기 PR 을 스스로 한 번 훑고 올리는 게 정석입니다.

1. 01

   Files changed 탭에서 내가 뭘 바꿨는지 봅니다

   의도한 것만 들어 있는지 확인합니다. 실수로 딴 파일이 끼어 있으면 여기서 잡힙니다

2. 02

   Merge pull request 를 누릅니다

   22강의 git merge 와 같은 일을 깃허브가 대신 해줍니다

3. 03

   Confirm merge 로 확인합니다

   PR 상태가 보라색 Merged 로 바뀝니다

4. 04

   Delete branch 버튼을 누릅니다

   다 쓴 가지는 지웁니다. 22강의 가방 이야기 그대로입니다. 깃허브 쪽 가지만 지워진 겁니다

내 컴퓨터는 아직 모릅니다

여기서 한 번 걸립니다. 깃허브에서 합쳤으니 다 끝난 것 같은데, 터미널로 돌아와 README.md 를 열어보면 master 에는 소개 문단이 없습니다.

• $ git switch master
• Switched to branch 'master'
• $ git pull origin master
• From https://github.com/내계정/my-first-repo
• * branch master -> FETCH_HEAD
• Fast-forward
• README.md | 2 +
• 1 file changed, 2 insertions(+)

이제 README.md 에 소개 문단이 들어와 있습니다. 22강에서 본 Fast-forward 가 또 나왔습니다. 이번엔 깃허브가 합쳐놓은 결과를 내 컴퓨터가 따라잡은 겁니다.

마지막으로 내 컴퓨터에 남은 add-intro 가지를 git branch -d add-intro 로 지웁니다. 깃허브 쪽은 아까 버튼으로 지웠고, 이건 내 쪽입니다. 양쪽에 하나씩 있었으니 양쪽에서 지웁니다.

단계	장소
가지 만들고 커밋	내 컴퓨터 (터미널)
git push -u origin 가지	내 컴퓨터 → 깃허브
PR 만들고 합치기	깃허브 (브라우저)
git pull origin master	깃허브 → 내 컴퓨터
가지 삭제	양쪽 각각

혼자 쓰는데도 의미가 있나

있습니다. 두 가지입니다.

하나는 기록입니다. 몇 달 뒤 이력서에 링크를 붙일 때, 커밋만 있는 저장소와 PR 이 쌓인 저장소는 인상이 다릅니다. 무엇을 왜 바꿨는지 설명하며 일한 흔적이 보이기 때문입니다.

또 하나는 손에 붙는 것입니다. 팀에 들어가면 첫날부터 PR 로 일합니다. 그때 처음 배우면 늦습니다. 지금 혼자 열 번쯤 해두면 그냥 하던 일이 됩니다.

명령	하는 일
git push -u origin 가지이름	가지를 깃허브에 처음 올린다
git push	위를 한 번 했으면 그다음부터는 이것만
git pull origin master	깃허브에서 합쳐진 결과를 받아온다
git branch -d 가지이름	내 컴퓨터 쪽 가지를 지운다

정리하면

• Pull Request 는 내 가지를 master 에 넣기 전에 "넣어도 될까요" 하고 올려두는 결재입니다
• PR 은 깃허브 기능입니다. git pull-request 같은 명령은 없습니다
• PR 을 만들려면 먼저 가지를 깃허브에 올려야 합니다. git push -u origin 가지이름
• 올리고 나면 터미널에 remote: 로 PR 만들 주소가 찍힙니다. 복사해서 열면 됩니다
• PR 화면의 base 와 compare 방향을 확인합니다. 왼쪽이 받을 쪽입니다
• 설명 칸에 마크다운이 먹습니다. 11~13강이 여기서 또 값을 합니다
• Files changed 에서 줄 단위로 댓글을 답니다. 이게 PR 의 진짜 쓸모입니다
• 합치는 것은 Merge pull request 버튼입니다. 22강의 git merge 와 결과가 같습니다
• 깃허브에서 합쳤다고 내 컴퓨터가 아는 게 아닙니다. git pull 로 받아옵니다
• 가지는 깃허브 쪽과 내 컴퓨터 쪽에 하나씩 있습니다. 양쪽에서 지웁니다
• 혼자 해도 남습니다. 무엇을 왜 바꿨는지가 기록으로 쌓입니다

여기까지는 여전히 혼자 한 일입니다. PR 을 올린 것도 나고, 합친 것도 나입니다. 결재를 올리고 내가 도장을 찍은 셈이라 좀 이상합니다.

다음 25강에서는 사람을 한 명 부릅니다. 옆자리와 짝을 지어 서로의 저장소에 협업자로 초대하고, 남의 저장소에 PR 을 올려봅니다. 16강에서 만났던 403 Permission denied 가 왜 났는지, 어떻게 하면 그 문이 열리는지가 그때 풀립니다. 그리고 Issue 로 "이거 고쳐주세요" 하고 일을 주고받는 것까지 해봅니다. 드디어 남과 하는 깃입니다.