git
Branch?
- 독립적으로 어떤 작업을 진행하기 위한 개념
- 각 브랜치는 서로 영향을 받지 않기에 여러 작업을 동시에 할 수 있다.
github flow 전략
- 간단하다.
- 두가지 브랜치만 존재 (master, feature)
- 바로 수정 후 병합으로 진행한다
git flow 전략
- 크게 세 개의 브랜치 전략 (master, pre-production, production)을 취한다.
- 배포 전에(master에 올리기전에) staging을 한 번 해보고 올릴 수 있는 전략이다.
master: 제품으로 출시될 수 있는 브랜치
develop: 다음 출시 버전을 개발하는 브랜치
feature: 기능을 개발하는 브랜치
release: 이번 출시 버전을 준비하는 브랜치
hotfix: 출시 버전에서 발생한 버그를 수정하는 브랜치구성 예시
master | develop | | f.e b.e | feature...pull & push
push 전 pull하는 습관들이기
push : local repository > remote repository
pull: remote repository > local repositorymerge request(MR)
- 병합 대상 브랜치와 병합될 브랜치를 잘 구분하고 유의하여 병합하기
- feature 머지를 바로 master로 하면 git이 꼬일 수 있다는 점 주의
- title과 description 작성을 통해 merge request를 만들 수 있다
- 코드 리뷰 후 머지할 수 있다는 옵션도 있다는 점 유의하기
- comflict가 없으면 Merge버튼 활성화 되고, branch를 삭제할 지를 묻는 옵션이 있으니 확인하자
Conflict를 방지할 방법들
- 다른 사람이 작성한 코드는 임의로 건들지 말자
- git pull을 통해 원격 저장소와 로컬 저장소를 자주 동기화 하자
- master와 develop 브랜치에 직접 push를 자제하고, mr를 날리자.
- commit과 push를 생활화 하자.
Jira
jira?
버그 추적, 이슈 추적, 프로젝트 관리 기능을 제공해준다.
Jira 사용하기
- 백로그에서 스프린트 생성
- 스프린트에 이슈 등록
- 생성된 이슈에 스토리 포인트 설정
- 스프린트 시작
- 이슈관리
- 스프린트 종료
백로그? 스프린트?
- 백로그 : 프로젝트에서 해야하는 일(요구사항)을 보여줌
- 스프린트: 스크럼 보드의 개발 주기 단위
Issue
오류, 버그, 새로운 기능, 작업요청, 질문이나 의견 등 개발에 대한 모든 것
Issue의 종류
- EPIC (큰틀)
- STORY (이야기) : 회원 관점에서 작성 EX) 로그인을 한다
- TASK (작업)
- SUB-TASK (부작업)
- BUG (버그)
구성을 어떻게 할 지는 팀의 재량
EPIC -> STORY또는EPIC -> TASK처럼 단순하게 구성할 수도 있고.
EPIC -> STORY | TASK처럼 EPIC아래에 수평적으로 구성하되, 비 개발적 요소는 STORY, 개발적 요소는 TASK에 넣는 방법도 있다.
EPIC -> TASK -> STORY처럼 3단 상하관계로 놓아도 된다
ㅤSpint 생성하기
백로그에 이슈생성해서 만들거나, 만들어져있는 이슈 가져와서 생성하면 된다.
스프린트가 생기면 이슈 생성 버튼을 통해 만들어서 넣어줘야 한다.
스프린트 시작 -> 스프린트 이름, 시작 종료 시간 설정
활성 스프린트로 이슈가 이동된다.
ㅤIssue 생성하기
이슈는 스토리, 작업, 버그, 에픽 중에 선택하여 만든다.
밑에 이슈를 스토리, 작업에 연결하고 싶은 경우 연결할 이슈를 선택하면 된다.
담당자 선택을 잘하자
하나의 이슈는 최대 4스토리 포인트다
인당 8시간 -> 하루 8스토리 포인트로 배정하자.
그 외
레이블 사용 선택이고 예를들어 로그인과 같은 레이블을 붙여 사용하면된다.
금요일에 퇴근전 스프린트 완료 버튼으로 강제적으로 끌 수 잇음
할일에 넣어있던 이슈는 백로그에 다시 넣어서 다음 스프린트에 넣을 수 있다.컨벤션에 유의하자.
[DEV]
[PLN]
[ETC]
등 말머리 정해놓아 사용하는 게 좋다.