일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- 배포 프로세스
- 윈도우키보드
- AWS
- 컴포지트패턴
- 대규모 시스템 설계
- Infra
- gitops
- Golines
- 배포 파이프라인
- Buffered channel
- AWS Infra
- UnBuffered channel
- goland
- http 413
- apollo router
- Helm V3
- notification system
- GoF 디자인패턴
- Intellij
- 디자인패턴
- Bastion Server
- System Design
- body size
- intellij ide
- GoF
- Kubernetes
- golang
- Logrus
- tenneling
- go
- Today
- Total
Fall in IT.
Bitbucket을 활용하여 코드리뷰하기 본문
Bitbucket을 활용하여 코드리뷰하는 방법
Git 기반의 플랫폼 Bitbucket의 Pull Request 기능을 사용하여 코드리뷰하는 방법.
사실 Pull Request 기능은 코드 리뷰를 위한 도구는 아니고, GitHub에서 오픈소스에 기여하기위해 제공하는 기능입니다. 하지만 이런 기능의 연장선으로 코드 리뷰를 위한 도구로 활용할 수 있습니다.
오픈소스의 경우 pull request 사용 방법
fork
: 오픈소스 프로젝트를 나의 원격 저장소(repository)로 이동(복사)합니다.clone
: 나의 원격 저장소에 fork된 프로젝트를 내 로컬 저장소(작업환경)로 내려 받습니다.commit
: 로컬에서 수정할 부분 또는 추가할 부분에 작업을 하고 commit 합니다.push
: 나의 원격 repository로 push 합니다.pull request
: 오픈소스 프로젝트로 pull request를 날려, merge를 요청합니다.
(※주의할점. 항상 원격지의 원본 소스를 pull 받으면서 작업해야 합니다. 안그러면 충돌 발생.
또한, pull request한 작업단위가 굉장히 크고 복잡하다면 reject될 가능성 100%..)merge or reject
repository에 커밋 권한이 있을 경우 사용 방법
- clone
: 원격지에 있는 프로젝트를 내 로컬 저장소로 내려받습니다. - commit
: 로컬에서 수정할 부분 또는 추가할 부분에 작업을 하고 commit 합니다. - pull request
: 코드리뷰 및 특정 브랜치로 pull request를 날려 merge 요청합니다. - review
: 리뷰어는 코드 리뷰를 실시하고 file 또는 line 단위로 코멘트를 하거나, 정상적일 경우 merge 합니다.
실제 사용 모습
bitbucket 페이지에서 Pull requests 버튼을 선택하고, create pull request 버튼을 클릭합니다.
pull request할 브랜치와 merge 대상 브랜치를 선택하고, title과 description을 리뷰어가 알기쉽게 상세히 작성합니다.
Create pull request 버튼을 선택하여 pull request를 날립니다.리뷰어는 bitbucket -> pull reqeusts 목록에서 선택.
- 리뷰어는 코드를 확인하고, merge 또는 decline을 처리 합니다.
- file 또는 line 단위로 코멘트를 작성 할 수 있습니다.
merge 처리
decline 처리
필요한 사항
업무연관성이 있는 개발자들을 함께 리뷰어로 설정합니다.
만약, 여러가지 제약으로 인해 업무 연관이 없는 개발자가 리뷰어가 될 경우, 비즈니스로직 검토 보다는 unit test를 활용하여 커버가 가능합니다. (비즈니스로직 검토하다 시간이 다감..)
git flow 역할에 맞게 적절한 pull request를 생성하여야 합니다.
예를들어, develop/feature/hotfix 등으로 브랜치명칭을 나눠 놓고, 급한건의 경우 hotfix 브랜치로 작업하고 pull request를 날려 리뷰어들은 hotfix의 알림에 대해서는 즉각적으로 피드백 할 수 있도록 운영하는 것이 좋습니다.pull request 시 작업단위 최소화 필요. (리뷰어들도 자기 일해야 하니까..)
pull request 신청시 commit 메시지는 최대한 상세하게 작성합니다.
사용 팁
그냥 merge하는 것 보다 rebase를 활용하여 merge를 실시하면 깃 트리를 복잡하지 않게 만들 수 있습니다.
리뷰어 다수 설정이 가능합니다.
bitbucket 설정에 몇명이 승인하면 머지되도록 설정이 가능합니다.
코드 리뷰가 단방향으로 진행되는 경우가 있는데 이는 지양해야 합니다. (코드리뷰를 하는 사람의 적극적인 자세가 필요.)
참고
'기타' 카테고리의 다른 글
간단히 화살표함수 알아보기 (0) | 2017.09.15 |
---|---|
화면 오버레이 감지됨 에러 해결 방법 (0) | 2017.08.18 |
SourceTree Command Line에서 실행하는 방법 (0) | 2017.07.23 |
oauth2에 대하여 (0) | 2017.06.14 |
ADC(Application Delivery Controller)란? (0) | 2017.03.13 |