-Git Flow 전략-

Sep 26, 2024

Contents

이 단계는 각 개발자가 현재 dev 브랜치로 이동한 후 최신 상태로 업데이트하는 과정

git pull origin dev: 원격 저장소(origin)에 있는 dev 브랜치의 최신 커밋을 로컬 dev 브랜치로 가져옵니다.

이 단계는 개발자들이 자신이 작업하고 있는 **기능 브랜치(feature branch)**로 돌아간 후, dev 브랜치에 적용된 최신 변경 사항을 자신의 브랜치 위에 재적용(rebase) 하는 과정입니다.

git rebase dev: dev 브랜치의 최신 변경 사항을 현재 브랜치의 커밋 히스토리 위에 재적용하여, 충돌을 해결하며 최신 코드베이스와 동기화합니다.

Rebase는 커밋 히스토리를 보다 깨끗하고 직선형으로 만들어 주는 장점이 있으며, 커밋 히스토리가 마치 하나의 타임라인처럼 보이게 합니다.

충돌이 발생할 경우 개발자는 rebase 도중 충돌을 해결한 후 git add 후 git rebase —continue (commit 다시 할 필요 없음)

모든 충돌을 해결한 후, 개발자는 PR(Pull Request) 요청을 합니다. 팀장은 이를 GitHub(또는 GitLab, Bitbucket 등)에서 검토하고, 필요한 경우 코드를 리뷰한 후 merge합니다.

팀장이 PR을 승인하고 병합할 때 Non-Fast-Forward 병합을 하도록 설정

Fast-Forward 병합은 중간에 새 커밋이 없을 때, 브랜치를 그냥 앞으로 옮기는 방식입니다. 하지만 Non-Fast-Forward 병합은 새로운 병합 커밋을 생성하여, 브랜치가 병합된 히스토리를 명확하게 기록하는 방식입니다.

이 방식은 병합 기록이 남기 때문에 프로젝트 히스토리를 추적하고, 나중에 문제가 발생했을 때 어느 브랜치에서 어떤 기능이 병합되었는지를 명확히 할 수 있다는 장점이 있다.

GitHub

type	subject	body(선택 사항)	footer(선택 사항)
feat: 새로운 기능 추가	제목은 최대 50글자를 넘기지 않는다.	본문은 한 줄당 72자 내로 작성한다.	이슈 트래커 ID를 작성한다.
fix: 버그 수정	ㅤ	양에 구애받지 않고 최대한 상세히 작성한다.	"유형: #이슈 번호" 형식으로 작성한다.
docs: 문서 수정	마침표 및 특수기호는 사용하지 않는다.	어떻게 변경했는지 보다 무엇을 변경했는지 또는 왜 변경했는지를 설명한다.	여러 개의 이슈 번호를 적을 때는 쉼표(,)로 구분한다.
style: 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우	ㅤ	ㅤ	Fixes: 이슈 수정 중 (아직 해결되지 않은 경우)
refactor: 코드 리팩토링	ㅤ	ㅤ	Resolves: 이슈를 해결한 경우
test: 테스트 코드, 리팩토링 테스트 코드 추가	영문으로 표기하는 경우 동사 원형을 가장 앞에 두고 첫 글자는 대문자로 표기한다.(과거 시제 사용 금지)	ㅤ	Ref: 참고할 이슈가 있을 경우
chore: 빌드 업무 수정, 패키지 매니저 수정, production code와 무관한 부분들 (.gitignore, build.gradle 같은)	ㅤ	Related to: 해당 커밋에 관련된 이슈 번호(아직 해결되지 않은 경우)	ㅤ
comment: 주석 추가 및 변경	ㅤ	ㅤ	ㅤ
remove: 파일, 폴더 삭제	ㅤ	ex) Fixes: #45 Related to: #34, #23	ㅤ
rename: 파일, 폴더명 수정	ㅤ	ㅤ	ㅤ