(3D)Dev Deep Dive/Templates & Guides

[GitHub] Git에서 팀 단위로 협업하기

  • -
728x90

0. 문제 상황 파악하기

가장 먼저 해야 할 일은 현재 프로젝트에서 내가 무엇을 해야하는가에 대한 이해와 이 문제를 해결하기 위해 어떤 것을 활용하느냐 입니다.

그 부분을 잘 알고 있으시다면 분명 원활한 협업이 이루어질 것이라고 생각하며 글을 시작합니다.

 

어느정도 초반 세팅이 되어있다면 프로젝트에서는 2~5번을 반복합니다.

 

1. 프로젝트 클론 받기

우선 개인 컴퓨터가 준비가 되셨고, 팀 organization이 있다면 그 안에 프로젝트 레포지토리로 들어가줍니다.

팀원과 함께 프로젝트를 함께 세팅을 했을 것이고, 그 프로젝트 파일이 당신의 컴퓨터에 존재하지 않는다면 이 과정을 거치도록 합니다.

이 글에서는 프로젝트가 진행중인 frontend를 기준으로 설명드리겠습니다.

 

우선, 작업을 하려는 레포지토리로 들어갑니다.

 

< > Code 를 누르고 나오는 링크를 복사해서 클론을 받습니다.

 

2. 이슈 생성하기

다음으로 무엇을 해야하는 지 태스크를 분배받거나 문제 상황을 인식하고 있으시다면

이슈를 생성해서 모든 이들이 당신이 무엇을 할 것인지에 대한 정보를 받을 수 있게 할 것입니다.

 

여기서 New Issue를 클릭합니다.

 

여기서 작업의 종류에 따른 이슈 템플릿을 선택합니다.

 

제목과 내용을 입력하고 우측의 항목들을 설정합니다.

Assignees는 작업하는 사람을 선택합니다 (여기서는 본인이 갈 것이므로 본인을 선택합니다)

Labels는 이 작업을 나타내는 태그를 선택합니다 (여기서는 기능 구현만을 할 것이므로 feature만 선택합니다)

Projects는 Organization에서 생성해 둔 Project를 선택합니다. (저희 프로젝트의 이름인 Rememeber Plus를 선택합니다)

MileStone에는 스프린트 단위로 쪼개놓은, 미리 생성해둔 마일스톤을 선택합니다. (2주차이므로 2주차 프로젝트를 선택합니다)

 

결과는 다음과 같습니다

그렇게 이런 느낌으로 등록을 하고 이슈를 생성합니다
선택한 Projects에서는 이렇게 진행중인 프로세스를 보실 수 있습니다.

 

3. 브랜치 생성하기

이슈가 생성되면 그 다음에는 브랜치를 만들어서 작업을 하게 됩니다.

사전에 정한 branch naming convention에 따라 이름을 정하고 브랜치를 생성합니다.

저의 경우에는 기능종류/간단한-기능설명-이슈번호[ex) feat/login-page-123]로 생성하였습니다.

 

그 후 각자의 브랜치에 체크아웃 한 후 작업을 한 후 commit을 하여 원격 브랜치에 작업내역을 저장합니다.

 

4. Pull Request 요청하기

모든 작업이 끝나면 PR을 요청할 것입니다.

PR의 경우에는 아래의 화면에서 오른쪽 초록색 버튼 New pull request를 눌러 생성해줍니다.

 

pull request를 누르면 생성되어 있는 브랜치가 하단에 보여집니다.

1. 그 브랜치를 눌러서 base 브랜치에 병합 할 pull request를 작성하시거나

2. 상단 compare 부분에서 작업하신 브랜치를 선택하고 Create pull request를 누릅니다.

 

그렇게 브랜치를 누르실 경우 다음 화면과 같이 커밋 내역과 변경사항들이 보여지게 됩니다.

 

그렇게 미리 제작된 PR 템플릿이 존재한다면 아래와 같이 나타날 것입니다.

물론 템플릿의 세부 내용과 우측의 항목들은 직접 선택해야 합니다.

Reviewers는 리뷰를 해주는 사람을 선택합니다. (여기서는 본인이 직접 리뷰어가 되지는 않습니다)

Assignees는 작업 한 사람을 선택합니다 (여기서는 본인이 갈 것이므로 본인을 선택합니다)
Labels는 이 작업을 나타내는 태그를 선택합니다 (여기서는 디자인 작업을 하였으므로 design을 선택합니다)
Projects는 Organization에서 생성해 둔 Project를 선택합니다. (저희 프로젝트의 이름인 Rememeber Plus를 선택합니다)
MileStone에는 이슈와 브랜치가 연결되어있으므로  자동으로 선택됩니다.

그렇게 생성을 한 후 Development에 이슈가 등록되어있는 것을 볼 수 있습니다.

 

이렇게 연결된 이슈, 브랜치, Pull request는 merge가 완료되면서 동시에 닫히며 적용됩니다.

 

5. 코드리뷰 하기

어찌보면 협업을 할 때 병합 이전의 가장 중요하고도 필수적인 요소중 하나는 코드리뷰일 지도 모릅니다.

자신이 작성한 코드를 타인이 확인을 해보며 오류나 더 나은 로직을 제안받을 수도 있기 때문이죠.

기본적인 설정에서는 스스로가 병합(Merge)를 할 수 있는 상태이겠지만 스스로 병합을 하는 것은 좋지 않은 습관입니다.

따라서 Branch Protection Rules 를 적용하여 브랜치가 무분별하게 병합되는 것을 방지합니다.

 

더 나은 설정이 있을 수도 있습니다.

여기서는 1명 이상의 리뷰어가 Approve를 해야하고, 모든 리뷰가 해결되어야만 merge 가능하도록 설정하였습니다.

 

코드리뷰는 Files changed 항목에 가서 진행됩니다.

변경된 파일들의 viewed를 눌러 봤다고 체크할 수도 있습니다.

 

이런 식으로 옆의 십자가 부분을 드래그 하여 특정 코드에 대한 리뷰도 남길 수 있습니다.

그렇게 리뷰 또는 comment를 남기고 나면 본인이 남긴 글 옆에 pending 이라고 나타나 있을 것입니다.

이 pending 상태를 해결하기 위해 Review changes를 눌러 commit이나 approve를 선택하시고 submit review를 눌러줍니다.


이렇게 Git을 활용하여 협업을 하는 과정을 정리해 보았습니다.

추가적인 설명이 필요한 경우 추후 업데이트를 통해 보완해두도록 하겠습니다.


End

728x90
Contents

포스팅 주소를 복사했습니다

이 글이 도움이 되었다면 공감 부탁드립니다.