[GIT] github branch를 활용해서 협업하기

1. 개요

과제에 대한 피드백에서 repo에 push할때 기능별로 파트를 분담해서 브랜치를 생성하고 코드를 관리하라는 내용을 받았다.

사실 팀프로젝트 경험이 거의 없고, 브랜치가 무엇인지 잘 몰랐기 때문에 이번에 제대로된 개념을 잡아놓을려고 한다. 또한, pull request가 무엇인지 그리고 코드 리뷰는 어떻게 하는 것인지를 공부할 것이다.

2. 브랜치(branch)

깃에서 협업을 할때 역할을 나눠서 코드를 관리하는 기능이다.

일반적으로 브랜치는 기능별로 나누어서 생성하고 push한다.

- 브랜치를 통한 협업의 전체적인 과정

1. 새로운 브랜치 생성
2. 로컬에서 원격 저장소로 브랜치 푸쉬
3. PR(Pull Request) 생성
4. 코드 리뷰
5. 코드 수정
6. 병합

- 원격저장소에 브랜치 push

다음의 예제는 sequelize에서 config 부분을 수정해서 branch를 생성하고 push하는 상황이다.

// sequelize-config 브랜치 생성
$ git branch sequelize-config

// sequelize-config 브랜치로 전환
$ git checkout sequelize-config

// add
$ git add .

// 커밋
$ git commit -m "sequelize config 수정"

// 원격 저장소에 push
$ git push origin sequelize-config

위와 같이 성공했다면 깃헙 repo에서 다음과 같이 브랜치를 확인할 수 있으며 pull request가 생성된다.

- pull requests란 무엇인가?

브랜치를 생성하고 push하면 항상 pull request라는게 생성된다. 이는 흔히 PR(Pull Request)라고 부르는데 새로운 기능이나 수정 내용을 원본 브랜치에 병합하고자 할 때 다른 개발자들에게 알리는 수단이다.

pull request를 클릭하면 다음과 같은 화면이 나올것이다.

여기서 Merge pull request를 클릭하면 main의 코드와 병합이 진행된다.

- 코드 리뷰는 왜 필요해?

협업을 할 때 다음과 같이 진행한다고 가정하자.

브랜치 생성 -> 푸쉬 -> Merge pull request

무엇이 문제일까?

위의 과정은 그냥 내 코드를 올리고 다른 사람들과 상의 없이 일방적으로 main과 합쳐버리는 것이다.

프로젝트 규모가 꽤 큰 회사를 가정해보자. 나는 신입 개발자이고 나와 3년차, 5년차 개발자 사수 두명이 작업을 수행하고 있다. 큰 회사들은 CI/CD가 구축이 되어 있어 main에 push를 하면 바로 배포로 옮겨지는 방식일 것이다. 그런데 만약 신입인 내가 팀원들과 아무런 상의도 없이 내 코드를 올렸다가 문제가 생기면 그것은 아주 안타까운 상황일 것이다.

위와 같은 일이 발생하지 않도록 팀원들의 코드 리뷰가 필요하고 리뷰가 완료되면 main에 merge하는 방식을 협업에서 사용하는 것이다.

- 코드 리뷰는 어떻게 해?

1. pull request를 선택해서 들어간다.
   

2. 상단에 File changed를 들어간다.
   

3. 코드에 수정되거나 추가된 부분에 마우스를 올리면 + 버튼이 생긴다.
   

4. + 버튼을 클릭하고 리뷰를 생성한다.
   

다시 돌아가면 다음과 같이 리뷰가 생성된 것을 확인할 수 있다.

- 병합(Merge)

이제 PR도 생성하고 코드리뷰도 마친 뒤 코드 수정까지 완료했다면 main에 merge를 한다. 이때 branch는 같이 삭제하는 것을 권장한다.

merge를 한뒤에 다음과 같이 버튼이 생성된다. Delete branch를 클릭하면 삭제가 완료된다.

삭제 후는 다음과 같다.

참고

튜터님께 1대1로 강의를 들었다..ㅎㅎ