Github가 여전히 어려웠던 이유
처음에 배울땐 명령어를 사용하지 않고 툴에서 지원해주는 방식을 사용하였다.
하지만 어느순간부터 툴에만 의존하게 되다보니 명령어 사용을 하나도 모르고 있었고
협엽할때 깃허브를 전혀 활용하지 못하고 있었다.
프로젝트 진행 전 구체적인 설계가 가장 중요하다.
개발은 혼자하는 것이 아니다. 각자 역활에 따라 기능별로 브런치를 만들며
브런치이름 명명하는 규칙 그리고 협엽시 커밋메시지 규칙을 정해 어떤 내용을 커밋했는지 알 수 있게 정해야한다.
프로젝트 진행 전 커밋메시지, 커밋 유형, 규칙, Issue에 대한 규칙 ,작성법 ,작은 단위로 쪼개어 커밋과 PR을 해야하는 것 브런치 네이밍, 개발 프로세스 등 신경써야 할 것이 많았다.
이번 프로젝트 때 좋은 팀원분 덕분에 알게 되어 앞으로 프로젝트 진행 전에 충분히 고심하여 모든 설계를 마친 후 프로젝트를 진행 할 것이다.
앞으로 깃관련하여 규칙을 정하는 예시
커밋 메시지
커밋 유형: 작업 내용 (#이슈 넘버)
- 커밋 유형
- bugfix: 버그 수정
- chore : 빌드 업무 수정, 패키지 매니저 수정
- del: 기능/파일 삭제
- docs : 문서 수정
- feat : 새로운 기능 추가
- fix : 코드 수정
- refactor : 코드 리펙토링
- style : 스타일 관련
- test : 테스트 코드, 리펙토링 테스트 코드 추가
규칙
- type은 소문자로 작성
- 제목 끝에 마침표 넣지 않기
- 명사형으로 작성
Issue
Github Project 이용해서 팀 이슈를 한눈에 파악
정의된 템플릿을 활용해 기능 구현, 버그 수정 구분하여 작성
- 규칙
- Label 사용해서 작업 유형 구분
- 제목은 [작업유형/기능명] 내용
- 작업유형은 위의 커밋 유형 준수
Issue 작성법
1.Issue 내용 작성
2. 담당자(Assignee)를 지정
3. 라벨 달기
PR
제목: 작업유형: 해결한 이슈 내용
Issue를 기반으로 작업을 수행한 뒤 PR (커밋과 PR은 최대한 작은 단위로 쪼개기)
정의된 템플릿을 활용해 PR 생성하고 git-flow 개발 프로세스에 따라 개발
브랜치
브랜치 전략
git-flow: 5가지의 브랜치를 이용해 운영하는 브랜치 전략. 그 중 4가지 브랜치 사용
- main: 배포 가능한 브랜치
- develop: 개발한 기능이 모여있는 브랜치
- feature: 기능을 개발하는 브랜치 (develop 에서 분기)
- fix: 버그를 수정하는 브랜치
브랜치 네이밍
- main
- dev
- feat/{feature_name}
- fix/{bug}
개발 프로세스
1.Issue 생성
- Issue 템플릿 사용
- Assignees, Labels, Projects 지정
2.Issue 제목에 명시한 브랜치명으로 dev에서 분기하여 브랜치 생성 git checkout -b feat/review - 로컬의 develop 브랜치는 항상 최신화 git pull origin dev
3.작업 브랜치에서 소스코드 수정
4.작업 브랜치에서 변경사항을 커밋 - 커밋 메시지 컨벤션에 따라 작성
- 작업 브랜치 최신화
a. 변경 사항이 없는 경우: git pull origin dev
b. 변경 사항이 있는 경우
a. git add, commit
b. git stash (아직 완료하지 않은 일을 커밋하기 껄끄러울 때 사용)
c. a와 b 중 선택. 이후에 git pull origin dev
- 작업 브랜치를 origin에 push git push origin feat/review
- dev 브랜치에 PR
- PR 템플릿 사용
- Reviewer, Assignees, Labels 지정
- reviewer들의 리뷰가 승인되면 본인이 merge (merge한 브랜치는 삭제)
- 최종 테스트 후 main 브랜치에 merge
- main 브랜치에서 버그가 발생한다면 hotfix 브랜치 생성
- 버그 수정이 끝나면 dev과 main 브랜치에 각각 merge
