1. 이슈를 처리하기 위해서 주 브랜치(master/main)에 바로 소스코드를 커밋과 푸시 하지 않아야함
2. 주 브랜치(master/main)에 바로 커밋과 푸시를 지양하며 특수한 경우가 아니면 개별 브랜치를 이용해야함
3. 브랜치 이름은 kebab-case로 작성해야 함 (ex: fix-employee-popup, modify-event-case, add-salary-menu, remove-location-setting 등)
4. 주 브랜치(master/main)에 소스를 반영하려면 개별 브랜치에서 풀-리퀘스트(Pull-reqeust)를 생성하고 리뷰어들의 리뷰를 받아야함
5. 리뷰어들은 풀-리퀘스트의 내용을 검토하고 승인 혹은 개선사항을 피드백해야함
6. 담당자는 리뷰어들의 피드백을 확인하고 수정
7. 마지막 리뷰어가 승인 혹은 개선사항을 점검하고 개선사항(다른 리뷰어들의 개선사항 포함)이 1건도 없으면 해당 풀-리퀘스트를 통해 개 별 브랜치를 주 브랜치(master/main)에 머지
8. 담당자는 풀-리퀘스트를 통해 머지된 개별 브랜치를 제거
<<PR 코멘트 작성법>>
1. (pr 이 들어온 상태를 가정) Files changed 탭에서 파일 별로 검토를 하면서 코멘트는 남길 부분에서 [+] 버튼을 클릭하면 다음과 같은 화면이 나타남
2. write 탭에서 코멘트할 내용을 기입후 [Start a review]를 클릭하면 해당 코멘트 내용이 임시저장[Pending] 된다. 임시저장을 하지않고, 즉시 코멘트를 남기고 싶으면 [Add Single Comment]를 클릭하면 저장과 동시에 바로 pr 요청자에게 notify가 된다.
3. 2에서 [Start a review] 로 pr의 모든 comment를 작성이 완료되었으면, 상단의 [Finish your review]를 클릭하면 다음과 같은 화면이 나타나고, 종합할 comment 내용을 기입후 [Submit review]를 클릭한다.
Comment: comment만 남긴다.
Approve: comment와 함께 merge를 승인한다.
4. merge(squash) 가 완료되면 해당 브랜치를 삭제하겠냐는 메시지가 나오고 delete branch 하면된다.
[TODO] : pr에서 변경된 사항을 내가 고치고 싶거나, merge 시 제외할수있는 쉬운 방법은?
'Git' 카테고리의 다른 글
Gitlab 소스 내려받기 (0) | 2023.07.26 |
---|---|
cherry-pick (1) | 2023.01.27 |
Git 서버 - SSH 공개키 만들기 ~ SourceTree 연결 (0) | 2021.09.28 |
Git Bash 사용법(2) (0) | 2021.08.30 |
Git 사용법 (0) | 2019.10.02 |