1월 12일 여정 4일차이다.
어제(1월 11일) 팀프로젝트를 마무리 짓고, 깃허브에 대해 깊이 공부하고 있었다.

오늘의 Today I Learned

Problem

깃허브를 공부하면서 Fork라는 개념이 도저히 이해가 안되었다. Fork로 누군가의 repo를 복사하여 작업 수행 후 pull request(PR)을 보낸다. 이게 도대체 무슨 말인가?

try

부트 캠프에서 제공하는 여러 Notion 문서를 읽어보았다. 그렇지만 전혀 이해가 되지 않았다. 구글에 검색을 시도해 보았지만, 위의 결과와 마찬가지였다.

solve

같은 팀원의 조장에게 깃허브 Fork 연습을 도와달라고 부탁하였다.
일단 기본적으로 조장은 깃허브에 빈 repo를 만들고 그곳에 파일 하나를 넣어 Fork하게 도와주었다. Fork를 하자 나의 깃허브 목록에는 내가 Fork한 repo가 떴다. 그리고 git bash로 나의 Fork 목록(복사한 곳의 깃 주소가 아닌)에서 clone을 하였다. 그리고 나의 브랜치를 만들었다. 그러나 push에서 막혀버렸다. permsion 거부가 뜬 것이다.
조장은 이것 때문에 Collaborators 초대가 필요하다고 말하였다. 초대를 받고 다시 push를 했을 때는 정상적으로 push가 되었다.
그러나 다른 문제가 생겼다. 내가 push한 파일을 조장은 볼 수가 없게 되었다.
그 이유 복사한 곳의 깃 주소가 아닌 내 Fork 목록에서 복사하였기 때문이었다.
push가 성공적으로 되자, pull request가 깃허브 홈페이지에 나타났다.
바로 이게 PR이었던 것이다.
이것은 이제 main에 있는 repo와 브랜치의 버전을 동일하게 만들어준다는 것이었다. pull request를 보내자 조장이 허락해주었다. 그리고 정말로 main으로 가보니 나의 브랜치와 똑같이 index.html이 만들어져있었다.

knew

1. 상대방이 Fork 후에는 push를 permission하기 위해 꼭 Collaborators 초대를 해야한다.

2. 나의 포크해온 깃허브 주소 말고 꼭 Fork한 상대 깃 주소로 clone을 해야된다.

3. pull request는 나의 브랜치에서 버전과 main의 버전을 동일하게 만드는 작업이다.

브랜치로 작업을 할 때는 코드 커밋 이력을 쉽게 볼 수 있었지만, Fork로 작업 할 때는 원본 저장소의 이력을 보려면 주소를 추가 해야한다고 한다.

마지막으로

Fork에 대해 알게 되니까, 뭔가 깃허브를 마스터 한 것 같았다.
막혀 있던 속이 뻥하고 뚫리는 기분이 내일 일이 잘 풀릴 것 같다.