개발 규칙 가이드

(by 깐깐징어)

Gitlab Flow 기반 브랜치 관리 전략 사용

Gitlab Flow 소개

기능 개발 전, Issue를 추가해볼까..

1. 작업 필요한 task에 대해 Github Issue로 만들기

• Issue 생성 시 Project - OAO 지정하면 backlog 자동으로 생김!
• Issue 내용은 Issue template 규칙을 따라가자.

    💡 구분: 내용
    
    ex) feat: 모달 레이아웃 개발, fix: login api 버그 수정

2. Github Project 에서 backlog 추가되어 있을것임 (issue 이름과 동일하게 만들어짐)

• 생성 확인 후 status만 todo or done ... 으로 변경해주기!

3. Issue에서 feature branch 생성

• Create a branch 클릭

• branch 이름도 자동으로 생성된다! 기본 설정 그대로 두기

• 복사해서 local terminal(local 저장 위치)에서 복사+붙여넣기

개발을 할 때는 개발 일지를 써보자!

• 직면한 문제 + 해결 과정을 Trouble shooting Wiki에 적어서 팀원들에게 작업 내용을 공유해주자!

열심히 개발을 한 당신, Commit을 해보자

• git add . 보다는, 협업을 하는 당신, 꼭 추가가 필요한 파일만 넣어볼까?! (conflict 방지)

  ☑️ commit convention 준수하기!

Merge를 할 때는 PR을 날려볼까?

• PR template을 따라가보자!

앗, conflict가 발생했다?!

목적: PR을 매일 아침 리뷰 후 merge하는 작업 방식을 채택했기 때문에, main으로 바로 merge해서 commit을 올리는 것이 아니라, issue branch에 main commit들을 옮긴 후 main으로 다시 PR을 날리는 방식.

• issue branch에서 변경 부분 stash or commit
• git checkout main
• git fetch origin
• git pull (main branch update)
• git checkout [issue branch]
• git stash pop (stash 한 경우)
• git rebase main (추가 확인하면 좋을듯..)
• conflict 해결
• git add .
• git commit + push
• main으로 PR 날리기

매일 오전 시간에 PR Review!

• 작업 내용 및 Trouble Shooting 기록, 의사결정 기록을 공유하자.
  • PR에 위키 링크를 올려서 팀원들이 빨리 파악할 수 있게 도와주자!
• 내가 어떤 의사결정을 했고, 어떤 방식으로 해결했는지 팀원들과 공유하고 서로 의견을 교환하자.

Review 이후 main branch에 merge가 되었다면, Issue, backlog를 닫자!

• feature 개발의 진정한 마무리,,!
• 개운한 마음으로 닫아버리자.