세미 전에 원격 깃 배워놓고, 프로젝트가 바로 시작하는 바람에 정리하지 못했다. 그러니 오늘은 Github를 통한 Remote Git를 정리해봤다.
일단, Remote Git과 Local의 차이는 저장 공간의 규모가 더 커진다는 것이다.
이로 인해 우리가 저장한 데이터는 로컬과 리모트에 원본이 각각 저장되고 이를 “분산처리”라고 한다.
Pubilc : 모두가 볼 수 있고, contribution이 있어 다른 이들이 참여할 수 있다.
*contribution은 오픈소스 프로젝트라서, 우리가 기여하면 (주인장 승인) 일종의 스펙이 된다.
Private : 비공개
Add a README file, Add .gitignore : 직접 처리
Choose a license : 오픈소스 생성에 기여할 라이센스 방식들을 선택
*origin : 관습적으로 정하는 리모트 저장소 이름
현재 깃허브 레포는 오픈 소스(public)으로 해둬서 다운로드는 자유롭다. 그러나 업로드는 제한이 되어 있다.
결과적으로 데이터 교류는 로컬과 리모트 사이에서만 일어나며, 워킹 트리는 체크 아웃으로 브랜치만 변경하는 것이다.
깃 허브로 협업을 하는 방식은 2가지가 있다.
담당자가 리모트 공유 메일을 조원들에게 보내고, 참여하게 되면 모든 공유자가 해당 리모트에 대한 주인이 된다.
즉, 모두가 push, pull이 가능해지는데 이 경우 멀티 스레드에 의한 동시성 문제가 있기 때문에 신나는 충돌 파티가 벌어진다. 그래서 익숙하지 않은 초급자들에겐 추천되지 않는다.
한 명의 리모드 주인 – 다수의 참여자
먼저 풀리퀘스트는 담당자가 리모트를 개설하면서 시작된다.
그러면 참여자들은 담당자의 리모트를 자신의 리모트로 끌고 오는데, 이를 fork라 한다.
그 다음, 복사본을 자신의 로컬로 가져온다.
이 경우, 담당자만 push가 가능하며, 다른 참여자들은 PR을 담당자에게 신청하여 본인이 로컬에서 작업한 내용을 담당자의 원격 리모트에 반영한다.
포인트는 ‘버전을 올라갔다면 조원은 자신의 리모트 저장소로 푸쉬해야 한다’이다.
솔직히 세미 3주동안 하면서 느낀 건, 담당자 시간에 PR신청을 맞추는 것이 아니라 담당자가 참여자들의 시간에 맞춰야지 프로젝트가 능동적으로 돌아갔다.
한가지 문제점은 그럼 버전이 올라가면, 기존에 작업하던 내용은 어떻게 될 것인가이다.
그때 내가 썻던 방법은 PR이 승인되면 모두가 하던 작업을 “commit”한다. 물론 각자의 fork 레포에는 올리지 않는다.
이렇게 되면, 자동으로 커밋 내용과 pull한 내용이 겹쳐져서 작업내용이 안 날라간다. 추후 작업이 완료 되면 fork.레포에 push 후 pr을 신청한다.