[GIT] 깃허브로 협업하기 | Repository 공유, PR, merge

Jae_0·2023년 9월 17일

[GIT] 깃허브로 협업하기

저번학기 캡스톤 디자인때 협업을 처음 하며 수많은 시행착오를 겪었다.
특히 깃허브로 프로젝트를 공유하며 서로 개발을 진행한 점인데, 나를 포함한 모두가
개인적인 깃허브 코드 관리는 어려워하지 않았으나, 공용리포를 만들고, 브랜치를 뻗어
작업 하고 Pull Request(PR)을 날려, Merge 하는 과정까지 우여곡절이 많았다.

실무 뿐만 아니라 스터디등 필수로 사용하는 기술이기에 처음 접하는 사람도 보기 쉽게 정리해본다.

Contributor와 Collaborator 총 두 가지의 방식으로 나눠 정리한다.
게시물에 나오는 git 명령어에 관한 글

Contributor

Contributor는 프로젝트 자체를 관리 할 수는 없지만, 해당 프로젝트 커밋에 관여가 가능하다.
Push권한은 리포지토리 소유자와 Collaborator만이 가지고 있으므로 PR을 활용해야 한다.

1. Fork

먼저 프로젝트 리포지토리를 Fork 하여 자신의 깃허브로 가져온다.

2. Clone, Remote

Fork한 리포지토리에서 URL을 복사후, 로컬 환경에 Clone 한다.

  $ git clone [url]
ex) git clone https://github.com/JaeYoung24/collabo-test.git

원본 프로젝트를 원격 저장소로 등록한다.

   $ git remote add [별칭] [원본 repo url]
 ex) git remote add upstream https://github.com/JaeYoung98/collabo-test.git

3. git branch 생성

branch를 만들어 로컬 환경에서의 작업 준비를 한다.

// 브랜치 생성
$ git branch [name]
// 브랜치 이동
$ git checkout [name]
// 브랜치 생성 후 바로 이동
$ git checkout -b [name]

4. 작업 후 커밋, 푸시

브랜치에서의 작업이 완료되면 커밋 - 푸시를 하여 자신의 리포지토리에 반영한다.

$ git push origin [branch name]

5. Pull Request (PR)

자신의 리포지토리로 이동하여 원본 리포지토리 관리자에게 PR를 보낸다.
comment를 작성하고 PR를 생성한다.

comment는 본인이 작업한 내용에 대해 자세히 기술 하는것이 좋다.

6. 코드리뷰 & Merge

원본 리포지토리 관리자는 Pull request 탭으로 이동해 생성된 PR를 확인 할 수 있다.
원본 리포지토리 관리자는 변경내역을 확인하고 Merge 여부를 결정한다.

7. 동기화

원본 리포지토리에 Merge가 완료되면 로컬 master 브랜치와 원본 리포지토리 코드를 동기화 해야한다.
- 자신의 리포지토리로 들어가 master 브랜치 확인 후, Sync fork -> update branch
이후 로컬에 있는 master 브랜치와도 동기화 해주고, 작업했던 브랜치는 삭제한다.

$ git checkout master
$ git pull origin master

// 브랜치 삭제
$ git branch -d [name]

// 원격 브랜치 삭제
$ git push origin --delete [name]

8. 반복

이제 3~7 과정을 프로젝트 완성까지 반복해주면 된다!

Collaborator

Collaborator는 리포지토리 공동 책임자이다. 즉, push, pull 권한 모두를 소유한다.
Collaborator는 원본 리포지토리 관리자가 직접 추가해줘야 한다.

콜라보레이터 추가

원본 리포지토리 관리자는 Setting -> Collaborator 탭으로 이동한다.
Add people 버튼을 눌러 검색창에 추가할 콜라보레이터의 깃허브 아이디를 입력하면 해당 이메일로 확인 메일이 보내진다.

Collaborator는 메일로 들어가 초대를 확인, 수락한다.

이제 해당 프로젝트의 공동 관리자가 되었다.

결론

공동 관리자라 할지라도, 본인이 작업한 것을 임의로 master 브랜치에 push 하는 것은 좋지않다.
Branch, Pull request를 통해 master 브랜치로의 병합을 하는 것이 좋아보인다.
협업을 할 때, 자신의 작업을 시작하기 전에 먼저 항상 pull 하여 작업을 진행 하는것이 좋을것 같다.