프로젝트: 청사진

[developerasun]

프로젝트 청사진

아키텍처

브랜치 전략

프로젝트 공통 브랜치 전략 수립 및 레포지토리 공통 적용

커밋 컨벤션

• 커밋 컨벤션과 동일

1. feat : 기능 개발 및 추가
2. bug : 버그 수정
3. docs : 리드미 등 문서 작성
4. chore : 에셋 업로드, 세팅, 메타 파일 등 그 외 파일 수정
5. refactor : 기존 코드 개선
6. test : 테스트 코드 작성

[developerasun]

2022.04.01에 #92 작성된 이후 가독성을 위해 옮겨짐

커밋 템플릿

#86 에 제안된 git commit 템플릿 설정을 여기와 여기를 참고해서 설정해보았습니당. 커밋 템플릿을 전체 PC에 적용하지는 않았고 하나의 레포지토리에만 따로 설정해봤어요!

워크 플로우

전체적인 플로우는

1. .gitmessage.txt 작성(커밋 컨벤션 작성하는 용도)
2. .gitmessage.txt를 아래 명령어를 통해 커밋 템플릿으로 지정

$git config --local commit.template .gitmessage.txt

3. git add, git commit을 통해 변경 사항 추가

하는 형식으로 진행하시면 됩니당

사용한 템플릿 공유

################
# feat: 
# bug: 
# docs: 
# chore: 
# refactor: 
# test: 
################

################
# feat: 기능 개발 및 추가
# bug: 버그 수정
# docs: 리드미 등 문서 작성
# chore: 에셋 업로드, 세팅, 메타 파일 등 그 외 파일 수정
# refactor: 기존 코드 개선
# test: 테스트 코드 작성
################

################
# <타입> : <제목> 의 형식으로 제목을 아래 공백줄에 작성
# 제목은 50자 이내 / 변경사항이 "무엇"인지 명확히 작성
# 예) feat : 로그인 기능 추가

[jshhhhh]

[Git] 커밋 메시지 템플릿 설정하기에서 보니까 git bash 말고 COMMIT_EDITMSG 파일에 커밋 제목과 본문을 남기는 방식인감?
결국 수동으로 타이핑해야 되면 git bash에서 하는 거랑 무슨 차이가 있는 거지🤔

[developerasun]

1. 필요한 접두사만 살려서 커밋 본문만 적을 수 있다는 게 장점 - 쓸데없는 타이핑 줄어들고 코드 변경 단위 구분이 확실해짐
2. 개발 팀원간 커밋 컨벤션 통일 효과

[developerasun]

커뮤니케이션

슬랙을 메신저 및 Push, Pull request 알림 용도로 활용.

• github app 활용, 작업 중인 repo와 슬랙을 연동

비효율적인 커뮤니케이션 로스를 막고 필요한 알림/공지사항에만 집중 가능. 메신저 상으로 상세 설명이 불가하거나 이미지/영상/코드 라인 등 추가 자료를 제시해야 할 경우 github discussion 란 활용

[developerasun]

브랜지 전략 2차 (수정 중)

추가 심화 튜토리얼 진행: https://github.com/DaeguDev/TIL/issues/31

기존: github flow + require code review for PR

변경 후

[jshhhhh]

Git branch 전략이라는 글에서 가져왔는데,
여기선 우리처럼 main에 바로 merge하는 게 아니고 develop이라는 브랜치를 한 번 더 거치는 거 같음
이런 방법은 어떻게 생각하십니까

[developerasun]

저도 develop 브랜치 하나 더 둘까 생각하긴 했었어요. 워크플로우 자세하게 설명 부탁드립니다

[jshhhhh]

위의 전략을 그대로 사용하기엔 너무 복잡해 보이고..
relase를 남기는 것도 물론 중요하지만 release의 zip 파일이 프로젝트 전부를 백업해주지는 못하는 것 같음
그래서 main에서 분기한 develop 브랜치를 하나 더 둠으로써 기존의 main 브랜치처럼 활용을 하되
release가 필요할 때 main 브랜치에 merge해서 이중으로 활용하는 게 어떨까 함

[developerasun]

git flow 살펴보면 메인 브랜치가 되는 main, develop은 삭제하지 않는 게 원칙이긴한데, 변형시켜서 사용할거면 원칙들은 미리 다 세워놓고 문서화 시키는 게 좋을 거 같아용 -

근데 설명한 방식은 git flow 랑 동일한데? https://github.com/DaeguDev/TIL/issues/31 이거 정리된 거 읽어보고 동일하게 이해했는지 체크 해주세용

[developerasun]

개발 방법론 (작성 중)

inspired by https://github.com/DaeguDev/TIL/issues/30

소프트웨어 개발 방법론 중 Agile 방식 채택.

• product backlog: 핵심 기능 논의 및 작성
• sprint backlog: 기능 파트별 배분 및 스프린트 기간 설정

Scrum

• 15 mins daily scrum
• sprint review after sprint

Sprint

협의된 기능 개발 중 각 팀원이 맡은 파트에 최소 1주 ~ 최대 3주의 기간을 배분.