저장소 포킹(Forking)

Git 학습에서 살펴본 모든 사람이 단일 저장소에 푸쉬(push)하고 풀(pull)하는 모델은 완벽하게 사용성이 높다. 하지만, 이 모델은 여러분이 저장소에 쓰기 권한을 가진 경우에만 동작한다. 때때로, 누군가의 저장소에 기여를 하고 싶지만, 변경사항을 푸쉬할 수 없는 경우가 있다. 대신에, Github에 목표로 하는 저장소의 사본을 생성하고, 복사한 저장소에 일단 변경사항을 푸쉬하고, 원 저작자가 검토 후에 여러분의 변경사항이 승인되어 원래 저장소에 변경되도록 요청한다.

늑대인간이 드라큘라의 Github 프로젝트에 변경을 하고 싶다고 가정하자. 새로운 프록젝트를 생성하는 대신에, 늑대인간이 드라큘라의 프로젝트를 포크(forks)한다. 즉, GitHub에 복제(클론, clone)한다. GitHub 웹 인터페이스를 사용해서 이를 수행한다.

그리고 나서 늑대인간은 자신만의 데스크탑 컴퓨텅에 사본을 생성하려고 드라큘라의 것이 아닌 자신의 GitHub 저장소를 복제(clones)한다.

이제 늑대인간은 자신의 컴퓨터에 변경사항을 저장할 수 있다. 프로젝트에 수정사항을 만들어 로컬 저장소에 커밋(commit)한다. 그리고 나서, git push를 사용해서 수정사항을 GitHub에 복사한다.

GitHub에 올라오게 되자마자, 새로운 잠재적 공동 협력자와 변경사항이 공유된다. 늑대인간은 자신의 포크를 공유하거나 다른 사람들이 변경된 늑대인간의 저장소를 포크할 수 있다. 늑대인간은 드라쿨라와 변경사항을 공유할 수도 있다. 논문을 게시하기 전에 늑대인간의 논문을 리뷰(review)하는 것과 마찬가지로,
드라큘라는 변경사항을 보고 피드백을 주거나 변경사항을 승인하여 자신의 저장소와 병합할 수도 있다.

마찬가지로, 늑대인간은 드라큘라가 만든 변경사항을 리뷰하고 자신의 프로젝트 포크에 병합할지 판단할 수 있다. 만약 드랴큘라가 중요한 기능을 삭제하기로 결정하거나, 완전히 프로젝트를 삭제하기로 결정한다면, 늑대인간의 수정되지 않는 사본을 유지한다. 가장 중요하게는 늑대인간이 유용한 수정사항을 생성하거나 공유하기 위해서 드라큘라가 자신의 저장소에 변경사항을 만드는데 늑대인간에게 권한을 줄 필요가 없다.

한 저장소에서 변경사항을 얻어오는 git pull와 변경사항을 다른 저장소에 적용하는 git push를 사용해서 이와 같은 리뷰와 병합 프로세스는 수작업으로 브랜치에서 수행한다. GitHub는 두 저장소가 변경사항 공유를 제안하는 도구가 있다: 풀 요청(pull request).

드라큘라와 변경사항을 공유하기 위해서, 늑대인간은 풀 요청(pull request)을 생성하고 드라큘라에게 “늑대인간이 변경사항을 저장소와 병합하고자 합니다”라고 통지한다.

풀 요청(pull request)는 병합이 일어나기를 대기하는 병합이다. 드라큘라가 풀 요청을 온라인에서 봤을 때, 늑대인간의 변경사항을 이해하고 논평할 수 있다. 풀 요청이 받아들여지기 앞서서 늑대인간과 드라큘라는 함께 여러차례 토의를 하고, 필요하면 브랜치를 갱신한다.

만약 친숙하게 들린다면, 이유는 이것이 과학 자체가 동작하는 방식이기 때문이다. 누군가 새로운 방법 혹은 결과를 발표할 때, 다른 과학자들이 즉시 이것 위에 무엇가 구축작업을 시작한다— 본질적으로 다른 과학자들이 자신만의 포크를 생성하고 변경사항을 커밋하기 시작한다. 만약 첫번째 과학자가 두번째 작업에 동의한다면, 다음번 논문에 이러한 발견을 통합하는데, 풀 요청을 병합하는 것과 유사하다. 만약 동의하지 않는다면, 두번째 작업에서 구축을 결정할지 혹은 두가지 접근법을 병합을 시도하는 것은 또 다른 과학자에게 달려있다.