728x90
이전 프로젝트에서 쓰던 방식을 정리해봤습니다.
1. 업무별 Repository 네이밍 규칙
Repository 네이밍은 다음과 같은 규칙을 따릅니다.
- 도메인명으로 Repository 네임을 결정합니다. 웹 서비스가 아닌 경우 com.company_name.레포명으로 작명합니다.
ex)
홈페이지 : company_name.com
쇼핑몰 shop.company_name.com
키오스크 : com.company_name.kiosk
2. Branch 전략
- 기본적으로 main 브랜치(trunk) 하나 만을 유지합니다. (트렁크 기반 개발)
- 작은 기능 단위로 feature 브랜치를 사용하여 수명이 긴 개발 브랜치를 만들지 않습니다.
- 운영 배포용 브랜치가 반드시 필요한 경우에만 deploy 브랜치를 별도 생성한 후 브랜치 보호 설정을 통해 배포 권한이 있는 사람에게만 권한 설정을 하여 배포. 기본 배포는 github 웹훅을 이용하여 slack 등으로 배포한다.
Branch 관리 시 주의점
- main에 코드를 속도감 있게 전달
- 작은 변경 사항
- 가능하면 하루에 최소 한번은 브랜치를 트렁크에 병합
- 지속적인 통합, 자동화된 테스트
- 지속적인 배포
- 피쳐 플래그(피쳐 토글)
feature 생성 시
- main 브랜치에서 fetch 👉 vscode 새로고침 아이콘 쓰시면 됨
- main 브랜치에서 새로 feature 브랜치 분기
feature 작업 완료 후
- feature 브랜치 작업 후 commit
- 작업 브랜치를 main 브랜치로 변경
- git fetch 👉 vscode 새로고침 아이콘 쓰시면 됨
- feature 브랜치를 main 브랜치로 merge
- 충돌 있으면 해결 후 commit -> push
- 충돌 없으면 merge된 main브랜치를 바로 push
- 반영이 완료된 feature 브랜치 삭제
3. Commit 규칙
해당 Commit 규칙은 모든 프로젝트에 공통 됩니다.
각 작업에 대한 Commit 시점은 다음과 같습니다.
- 작업 완료시 작업내용에 따른 헤더를 붙여 Commit Message를 작성합니다.
- 코드 작성이 완료되지 않은 경우 당일 작업 종료 시 기록합니다.
작업중일 경우 헤더를 -로 대체합니다. ex) - : ABC 기능 개발중 - Commit 전 반드시 Pull을 합니다.
- Commit Message는 헤더 : 내용 의 구성으로 작성해주시면 됩니다.
- Commit 후 Github로 바로 Push합니다.
헤더 | 작업내용 | Commit Message 샘플 |
---|---|---|
init | 초기화 | init : AB 프로젝트 초기설정 |
feat | 새로운 기능 추가, 기존의 기능을 요구사항에 맞추어 수정/삭제 | feat : 설정화면 추가 |
fix | 기능에 대한 버그 수정 | fix : 창크기 외부로 벗어나는 버그 수정 |
build | 빌드 관련 수정 | build : 32bit용 빌드 설정 추가 |
chore | 패키지 매니저, vscode, git 설정 수정 | chore : gitignore에 dev.env 추가 |
cicd | CI/CD 관련설정 수정 | cicd : ec2배포에서 ecs+fargate 배포로 변경 |
docs | 문서(주석) 수정 | docs : 로그인 컴포넌트 주석 추가 |
style | 코드 스타일, 포맷팅에 대한 수정 | style : 로그인 창 모양 변경 |
refactor | 코드 리팩토링 | refactor : 장바구니 추가 기능 최적화 |
test | 테스트 코드 추가/수정 | test : 로그인 컴포넌트 Unit Test 작성 |
release | 버전 릴리즈 | release : 1.1.1 릴리즈 |
4. CI/CD
- main 브랜치는 dev/stage 서버에 자동으로 배포되며 피쳐 플래그를 통해 제어합니다.
- deploy 브랜치는 배포담당자에 의해 운영 서버에 수동으로 배포됩니다.
- deploy 브랜치는 테스트가 있는 경우 테스트를 통과한 경우 배포합니다.
- deploy 브랜치는 테스트가 없는 경우 QA담당팀이나 담당자를 통해 검수 후 배포합니다.4.1 서버를 사용하는 앱의 경우
- github action을 사용하여 각 서버에 배포하는 것을 기본으로 합니다.
- deploy 브랜치에 변경이 있을 경우 자동으로 배포합니다.
4.2 실행파일 형태의 앱의 경우
- github의 release에 해당 버전의 수정 내역을 기록후 실행파일을 등록합니다.
※ 참고
내 PC에 Github 접속 설정하기
https://codechacha.com/ko/git-add-ssh-key-in-windows/
기존 프로젝트에 Github 연결하기(checkout main 과정 반드시 진행)
https://sowon-dev.github.io/2021/05/09/210510git-connectProject/
'TIP > Git' 카테고리의 다른 글
[Git] 원격 브랜치 삭제 (1) | 2024.10.16 |
---|---|
Git .gitignore에 새 파일을 추가할 경우 (0) | 2024.03.13 |
Github 여러 계정 쓰기 (0) | 2024.02.07 |
Git pull시 충돌났을때 (0) | 2023.10.24 |