PMPV
Github Desktop과 Fork를 이용한 깃 협업 플로우 - (2) 본문
2. remote repository
우리는 이제 커밋과 푸시의 개념을 잡았습니다. 그리고 원격 저장소에 대한 개념을 잡았습니다.
이번에는 이 깃허브의 원격 저장소를 이용해 협업을 하는 과정을 살펴보겠습니다.
깃허브에 가입한 사용자들은 각 계정에 소속된 원격 저장소를 생성하고 관리할 수 있습니다.
예를 들어, User라는 아이디를 가진 계정의 원격 저장소가 testApp, testGit 이렇게 두 개라고 가정하면 이 원격 저장소의 주소는 다음과 같습니다.
https://github.com/user/testapp
https://github.com/user/testgit
각각의 원격 저장소에는 권한을 가진 사용자가 푸시한 프로젝트가 들어있습니다.
협업을 할 때는 이 원격 저장소의 권한을 공유한다는 느낌으로 자신의 코드를 상대의 원격 저장소에 기여합니다. 첫 스텝은 깃허브에 올라와있는 원격 저장소의 프로젝트를 내 로컬 환경으로 가져오는게 먼저입니다. 우리는 여기서 Fork를 사용해보겠습니다.
3. Fork & Clone
이렇게 깃허브에 올라온 원격 저장소에 들어가면 오른쪽 상단에 포크 기능을 확인하실 수 있습니다. 저 버튼을 눌러 포크를 진행합니다.
포크가 완성되면 상대의 원격 저장소에 있던 프로젝트가 내 계정의 원격 저장소로 그대로 가져와집니다.
가져온 프로젝트를 클론 기능을 통해 내 컴퓨터, 로컬 환경으로 가져오시면 되겠습니다.
여기까지 진행되면 우리의 로컬 환경에서 타인의 프로젝트를 가져와 편집할 수 있습니다.
4. origin & upstream
편집하기 전에 콘솔에서 클론된 프로젝트의 경로로 이동해서 git remote -v을 확인해봅시다.
자신의 계정에서 클론했기 때문에 "origin" 이라는 이름의 원격 저장소만 있는걸 알 수 있습니다.
포크하기 전 원래의 저장소와 소통을 하기 위해서는 "upstream" 이라는 이름으로 새로운 원격 저장소를 추가해야 합니다. 사실, 이름은 상관없지만 upstream이 권장됩니다.
새로운 원격 저장소를 추가하는 명령어는 콘솔에서 다음을 입력하시면 됩니다.
git remote add upstream https://github.com/<포크된 저장소의 계정 아이디>/<포크된 저장소의 이름>.git
ex) https://github.com/kseymin/rubyshell.git
이렇게 하고 다시 한 번 git remote -v을 하시면 upstream이 추가된 것을 보실 수 있습니다.
-- why fork? --
지난 포스팅에서의 푸시는 원격 저장소 origin만을 이용해서 하던 내용이었습니다.
이번 포스팅에서는 원격 저장소가 두 개가 등장합니다.
1. 본인의 계정에 소속된 origin
2. 타인의 계정에 소속된 upstream
이렇게 원격 저장소가 두 갈래로 나뉘면 원래 프로젝트의 소유자가 아닌 타인이 커밋하고 푸시하는 내용이 타인의 포크된 저장소에만 반영되기 때문에 오리지널 코드를 해칠 위험이 없어집니다. 한 명의 팀원이 전체 팀 프로젝트를 엉망으로 만들 걱정이 없어진다는거죠! 그 외에도 포크의 강점은 많습니다만 이 한 가지 이유로도 충분히 강력하기 때문에 추가로 서술하진 않겠습니다. 궁금하시다면 구글링을 권유드립니다. 그렇게 배우는거죠 뭐
[180812 추가내용]
상단의 내용이 조금 부정확하다고 생각해 내용을 추가합니다.
타인의 저장소를 가져오는 방법 중에 가장 처음 접하는 방법은 보통 클론입니다. 클론을 하는 경우, 타인의 저장소에 대한 변경 권한이 없습니다. 커밋은 가능하지만 푸시를 할 경우 Permission denied라는 에러 메세지가 나오며 거절되는 것을 보실 수 있겠습니다.
이를 해결하는 방법 중 첫 번째는 깃허브 저장소에서 collaborator에 내 계정을 등록하는 방법입니다. 해당 저장소에 대해 푸시를 할 수 있는 권한을 얻게 되는데, 이런 경우 문제가 발생할 수 있습니다.
협업의 과정에서 브랜치와 커밋에 대한 규정을 지켜놓고 철저하게 따른다면 문제가 생기지 않겠지만 모든 팀원이 오리지널 저장소에 대한 모든 권한을 갖게 되는건 바꿔 말하면 누구나 오리지널 코드를 망칠 수 있다는 소리입니다. 잘못된 내용을 커밋하는 경우, 지우지 말아야 할 내용을 지우는 경우 등의 위험을 내포합니다.
두 번째 방법은 오리지널 저장소를 팀원 각각이 포크하여 사용하는 방법입니다. 포크된 저장소에 대한 권한은 나에게 있습니다. 이 때는 푸시에서 퍼미션 문제가 생기지 않습니다. 팀원들은 본인의 저장소에 작업한 내역을 커밋하고 푸시하며 오리지널 저장소에 병합을 요청합니다. 오리지널 저장소의 권한을 가진 사람은 병합 요청을 확인하고 문제가 없을 때 병합을 승인하면 됩니다.
다음 문단에서 변경 내용을 반영하는 병합에 대해 알아보겠습니다.
5. upstream 저장소에 변경 내용 반영하기 - pull request
이렇게 변경된 커밋 내역은 origin 저장소에 반영됩니다. 깃허브에서 확인해보겠습니다.
가장 아래 35분 전에 추가된 "test_git" 파일이 제가 작업한 내용입니다. upstream이 아닌 origin 저장소에 반영된 모습을 보실 수 있습니다.
그렇다면 upstream에 반영하기 위해선 어떻게 해야할까요?
upstream 저장소로 등록된 곳으로 나의 풀리퀘스트 요청이 들어가는 것을 확인할 수 있습니다.
하단엔 내가 몇 개나 커밋을 했는지, 어떤 내역을 변경했는지를 보여줍니다. 내역에 이상이 없다면 create new pull request를 선택합니다.
여기서는 풀리퀘스트 요청에 대한 메모를 남길 수 있습니다. 어떤 의도로 어떤 내역을 편집했는지에 대해 자세히 서술해주는 것이 좋습니다.
다시 한 번 create pull request 버튼을 누르겠습니다.
풀리퀘스트 요청이 성공적으로 마무리 된 모습입니다. 이 요청은 원작자의 깃허브에서 알림으로 뜨게 되며, 저장소의 풀리퀘스트 목록에서 확인할 수 있습니다. 원작자가 풀리퀘스트 요청을 검토하고 소스에 문제가 없다면 merge, 병합을 허락해줍니다. 이렇게 되면 origin 저장소의 변경 내역을 upstream 저장소, 오리지널 저장소에 반영할 수 있게 됩니다. 오리지널 저장소에 collaborator로 권한을 얻는다면 풀리퀘스트를 보내면서 머지도 직접 할 수 있습니다.
6. 오리지널 저장소의 변경 내역 최신화 하기 - fetch, pull, merge
출력 결과를 확인하겠습니다.
아무런 변경 내역이 없으면 출력 결과가 없습니다. 변경 내역이 있다면 이런 식으로 결과가 출력이 됩니다.
변경 내역이 있다는걸 확인했으니 이번에는 변경 내역을 가져올 차례입니다.
git merge upstream/master
업스트림 저장소의 마스터 브랜치를 우리의 프로젝트에 병합하겠다는 의미입니다. 정상적으로 병합이 완료되면 다음과 같은 출력 화면이 뜹니다.
이렇게 머지가 완료되면 로컬 환경에서도 최신화 프로젝트가 반영되어있는 것을 볼 수 있습니다.
이런식으로 최신화를 완료한 뒤 다시 새로운 작업을 진행하고, 다시 한 번 풀리퀘스트를 보냅니다.
포크를 사용한 깃 협업의 루틴은 이렇게 됩니다.
여기서 서술하지 않은 내용 중 fetch와 pull의 차이, 최신화 코드와 로컬의 코드에서 충돌 내역이 일어날 경우의 해결법 (conflict), 브랜치(branch)의 사용 등은 원활한 루틴을 위해 알아야 할 내용들입니다. 추후 시간이 되면 추가로 포스팅을 하겠지만, 이미 검색만 하셔도 아주 많은 설명이 있기 때문에 찾아보시는 것도 추천드립니다.
현 루틴은 모두 커맨드라인을 통해 작업이 진행됩니다. 이럴 경우 코드의 변경 내역, 구조나 로그 등의 시각화가 어렵습니다. 다음 포스팅에서는 깃허브 데스크탑이라는 프로그램을 이용해 조금 더 직관적으로 루틴을 진행하는 법을 살펴보겠습니다.
'development > Fxxk Git' 카테고리의 다른 글
| 조금 더 효율적인 협업 프로젝트 - Squash and merge, Github issue (1) (0) | 2018.08.30 |
|---|---|
| Github Desktop과 Fork를 이용한 깃 협업 플로우 - (3) (2) | 2018.08.12 |
| Github Desktop과 Fork를 이용한 깃 협업 플로우 - (1) (0) | 2018.08.09 |
