이번 소프트웨어 마에스트로 14기를 연수하면서 Github를 본격적으로 사용하게 되었는데, 우리 팀 역시 일반적인 Github flow 전략을 사용하기로 하였다.
이와 관련하여 겪었던 과정 및 시행착오들을 정리해보았다.
Coding Convention
- 항상 dev에서 feat 따서 진행 (dev에 직접 commit 금지)
- dev에서만 main에 merge 가능
- 모든 merge는 일반 merge로 하기
- merge한 뒤의 feat 브랜치는 삭제
- 모든 feat 브랜치는 이슈 등록 후 이슈 번호로 이름 지정
feat/#123
Issue
### TO DO
- 해야할 일 간략하게(필수)
### Description
- 세부 정보(선택)Pull Request
## 개요
- 관련 Issue 번호
## 작업사항
- 세부 정보Commit - Gitmoji 사용
##### 제목은 최대 50 글자까지만 입력
# <GITMOJI> <타입>: <제목>
🎉 feat: 무슨 기능 추가
# 이슈 reference 는 본문에 작성
Close #12
# 본문은 위에 작성
# --- COMMIT END ---
# <타입> 리스트
# feat : 기능 (새로운 기능)
# fix : 버그 (버그 수정)
# refactor: 리팩토링
# style : 스타일 (코드 형식, 세미콜론 추가: 비즈니스 로직에 변경 없음)
# docs : 문서 (문서 추가, 수정, 삭제)
# test : 테스트 (테스트 코드 추가, 수정, 삭제: 비즈니스 로직에 변경 없음)
# chore : 기타 변경사항 (빌드 스크립트 수정 등)
# build : 빌드, CI/CD 관련 사항
# ------------------
# 타입은 영어로 작성하고 제목과 본문은 한글로 작성한다.
# 제목 끝에 마침표(.) 금지
# 제목과 본문을 한 줄 띄워 분리하기
# 본문은 "어떻게" 보다 "무엇을", "왜"를 설명한다.
# 본문에 여러줄의 메시지를 작성할 땐 "-"로 구분
# 관련된 이슈번호는 제목 맨 뒤에 추가한다. ex. (#1)
# ------------------현재 원본 리포지토리가 morandi-server에 있고 나는 이 리포지토리를 fork하여 내 리포지토리에 morandi-server-SWM 으로 생성하였다.
일반적으로 이렇게 fork된 리포지토리에서 작업을 수행할 때 이슈, 브렌치를 만들고 커밋하며 Pull Request를 하는 과정은 다음과 같다.
- 원본 리포지토리에서 이슈 생성: 기능 추가 또는 버그 수정과 같은 작업을 시작하기 전에, 원본 리포지토리의 이슈 탭에서 관련 작업에 대한 이슈를 생성합니다. 이슈에는 작업에 대한 설명과 목표를 포함시킬 수 있습니다.
- Fork 리포지토리에서 브랜치 생성: Fork 리포지토리에서 작업을 위한 새로운 브랜치를 생성합니다. 일반적으로는 main 브랜치 또는 개발자들 간에 미리 합의된 다른 기본 브랜치를 기반으로 새로운 브랜치를 만듭니다.
- 로컬에서 작업: Fork 리포지토리의 새로운 브랜치를 로컬 환경으로 가져와서 작업을 진행합니다. 코드 변경사항을 커밋하고 푸시하여 원격 리포지토리의 해당 브랜치에 변경사항을 반영합니다.
- 원본 리포지토리로 Pull Request 생성: 작업이 완료되면, Fork 리포지토리에서 원본 리포지토리로 Pull Request를 생성합니다. Pull Request에는 작업한 내용과 관련된 이슈 번호를 명시합니다. 이렇게 하면 코드 변경사항과 이슈가 연결되어 변경 내용을 확인하고 리뷰할 수 있습니다.
이를 테스트 해보기 위해 readme.md를 수정하는 것을 이슈로 등록해보았다.
이슈를 등록하고 #5 임을 확인하고 나의 리포지토리 (fork) 에서 feat/#5를 만들고 이동 후에 readme.md를 수정하고 git add .를 작성했다.
그리고 gitmoji -c 를 통한 커밋을 이용하였고 git switch dev로 이동하여 feat/#5를 merge 하였다.
그리고 이 merge한 local branch dev를 remote branch dev에 push 하였다.
이렇게 되면 원본 리포지토리에 Pull Request를 할 수 있게 된다. 또한 여기서 main 브렌치에는 적용되지 않았지만 dev 브렌치로 변경하게 되면 push가 되어있는 것도 확인할 수 있다.
이렇게 나의 fork 리포지토리로 들어가면 Pull request 버튼이 생겼음을 알 수 있고 이것을 누르게 되면,
이렇게 morandi-server-SWM(fork 리포지토리)
-> SWM-NM/morandi-server(원본 리포지토리)로 이동하는 pull request를 보내는 것을 확인할 수 있다.
그런 다음 원본 리포지토리로 가서 확인을 해보면,
이렇게 Pull Request가 온 것을 확인할 수 있고 이를 반영하면
dev 브렌치에 성공적으로 push가 되는 것을 확인할 수 있다.
즉, 원본 리포지토리에는 main, dev 브렌치로 운영하고 fork 리포지토리에는 main, dev, feat/#x 로 운영하여 PR을 날리는 방식으로 github flow 전략을 적용할 수 있다.
