매주 무난하게, 또는 치열하게 과제를 해가며 어느덧 6주차 절반이 지나간 데브로드 코스. 트레이너님께 DM으로 나의 과제 제출 브랜치 주소가 항상 잘못되어 있었다는 연락을 받았다. 오타 강박이 있는 나로서는 어떻게 그런 일이 발생할 수가 있는지 너무나 충격이었다. 차라리 '코드가 잘못되었어요', '코딩 실력이 아직 부족하시네요' 이런 말은 참아도 어떻게 내가 이런걸 인지하지 못하고 지나쳤을 수가......... 심지어 이런 일로 남을 번거롭게 했어.......
그 사건이 도화선이 되어 CLI를 사용하지 않고 브랜치 생성하는 방법, 브랜치명의 대소문자를 구분하는 방법, 원본 저장소에 브랜치 push 하는 방법, Git의 origin, upstream 개념 등을 알아보았다.
1. 브랜치명 대소문자 구분하기
데브로드 과제를 제출할 때 프로세스는 다음과 같이 진행된다.
- 과제 repo를 fork한다.
- 과제 완료 후 원본 repo에 PR을 올린다.
- 과제가 통과되면 merge된다.
이 때 주의점이 ⚠️ base repository(upstream)의 main에 PR 요청을 보내는 것이 아니라, 이미 생성되어 있는 본인의 브랜치에 보내야 한다는 점이다.
🔗 TIL : git fork - 원본 저장소에 PR 요청하기를 작성할 때 캡쳐까지 해가면서 정리했는데 문제가 진작 발견되지 않은 것이 의아하다. 사실 발견했지만 대소문자 구분이 없나보다 하고 넘어갔다.
이상한 점은, 나는 분명 오타 내는걸 끔찍하게 싫어해서 브랜치를 생성할 때 아예 나의 깃허브 이름을 복사해 긁어온다는 것이다. 항상 CLI 환경에서 명령어를 사용해서 생성했다.
git checkout -b 브랜치 이름
그리고 방금 과제와 상관 없는 나의 개인 repo에서 내가 평소에 브랜치를 생성할 때 쓰는 동일한 방법으로 실험해 보았다.
정상으로 대소문자 구분되는 것을 확인했다.
혹시 대소문자 구분된 브랜치명과, 소문자 브랜치명 두가지 케이스가 중복 push 된 것일까 싶어서 브랜치들을 찾아봤는데, 그냥 소문자로만 잘못 올라간 것이 맞았다. 그렇다면 어째서 과제할 때만 이런 일이 발생한 것인지? 이유는 아직 찾지 못했다? 분명 나의 실수와 git 미숙의 콜라보 같은데...
💡 해결 방법
CLI가 아닌 Github에서 직접 브랜치를 생성하는 방법이 있었다. 이번 기회에 처음 사용해봤다.
1. 깃허브 repository 메인에서 branch 버튼 클릭
2. New branch 버튼 클릭 후 브랜치 생성
3. 대소문자 구분된 브랜치 생성 확인
2. 원본 저장소에 브랜치 push하기
그렇게 궁금증을 해결하고 과제를 제출하기 위해 push를 하려는데 또 문제가 발생했다. 트레이너님이 내 브랜치를 만들어놓으셔서 거기서 작업을 했는데, 내가 로컬에서 직접 만든 브랜치가 아니었기에 푸시할 때 오류가 생겼다. 그러니 이 문제는 원본 저장소에 특정 브랜치가 이미 만들어져 있는 경우 사용하면 되는 방법이다.
기존에 만들어져있는 해당 브랜치로 이동하면 'upstream/브랜치명' 이라고 표기된다. 이 상태에서 그냥 작업 내용을 push하려고 하면 다음과 같은 403 error가 발생한다.
fatal: unable to access '주소': The requested URL returned error: 403
403 Forbidden은 서버가 클라이언트의 접근을 거부할 때 반환하는 오류 코드이다.
🚨 권한이 없는 원본 repo 저장소에 직접 push하는 것으로 명령을 받아들였기 때문에 이런 오류가 뜨는 것이다. 처음 이 메시지를 보고 머리가 하얘졌다. 내가 원본 저장소의 뭔가를 건들인 줄 알고.. 그렇지만 에러 메시지는 친절하기 때문에 무엇이 문제인지 다 알려준다.
💡 해결 방법
origin 원격 저장소에 작업 브랜치를 push 한다.
git push origin 작업했던_브랜치_이름브랜치를 업로드하면서 커밋 내용도 push하는 방법이다.
3. Git origin과 upstream 차이
여기서 origin이나 upstream이라는 단어가 계속 보이는데, 예전부터 찾아봐야지 하고 미뤄두었던 내용이라 연계해서 학습하면 머리에 잘 남을 것 같아 알아보았다.
📌 Local, Remote
우선 로컬과 리모트를 알아보자.
- Local : 로컬 기기(컴퓨터 등)에 존재하는 모든 Repository
- Remote : 원격 저장소(Github)에 존재하는 모든 Repository
이 둘은 push, pull 명령을 통해 서로의 데이터를 주고 받는다.
- push : Local에서 ➡️ Remote로 업로드
- pull : Remote에서 ➡️ Local로 다운로드
📌 Origin, Upstream
Origin은 깃허브에 존재하는 repository(remote)를 의미한다. remote에 origin이라는 이름을 붙인 것으로, 깃허브에서 repo 생성 시 또는 깃허브에서 repo clone 시에 origin이 된다.
- origin : upstream
- local : downstream
origin은 upstream이고, local은 downstream이 되는데, push와 pull을 기준으로 생각했을 때 origin에서 ➡️ local로 흐르는 관계이기 때문이다.
📌 Fork 시 origin과 upstream
- 내가 포크한 remote Repository : origin
- 원본 remote Repository : upstream
⚠️ fork를 했을 때 혼란스러운 부분이 이 대목이다.
local과 origin의 관계에선 origin이 upstream, local이 downstream이 된다.
하지만 fork한 repository를 기준으로 보면 origin이 downstream, 원본 remote가 upstream이 되기 때문에 헷갈릴 수 있다.
내가 과제를 하며 원본 저장소에 git push origin 브랜치이름을 한 것은, 나의 포크해온 저장소에서 작업한 내용을 upstream에 올려 보낸 것이라고 이해했다.
연쇄적으로 여러가지 내용을 학습했는데, 이런 Git 다루는 방법은 협업할 때 필수적이므로 미리 알고 있으면 많이 유용할 것 같다. origin과 upstream도 많이 봤는데 이번에 제대로 알게 되어 시원해졌다. 참고로 이미 PR을 올려놓고서 계속 추가로 커밋-푸시할 경우에도 git push origin 브랜치이름 명령이 필요했다. 깃허브에서 직접 브랜치를 관리하는 것도 편하기 때문에(merge 후 브랜치 삭제 등) 브랜치 생성도 몇번 더 해봐야겠다.
'개발 > Git' 카테고리의 다른 글
| [Git] GitHub Actions 사용 방법 (0) | 2023.01.10 |
|---|---|
| [Git] Husky 사용 방법 (1) | 2022.12.29 |