weather-fit 협업 & SAM 가이드

안전한 브랜치 관리와 AWS SAM 기반의 효율적인 개발 프로세스

1. 브랜치 전략 및 병합 규칙

main ------------------ 운영 환경 (실제 서비스 배포용) ㄴ develop ---------- 통합 테스트 / 개발 환경 (기본 브랜치) ㄴ feature/* --- 개별 기능 및 Lambda 함수 개발

기능 개발 (feature → develop)

  • • PR(Pull Request) 생성 필수
  • • 팀원 최소 1명 이상의 Approve 승인
  • • Squash and Merge로 기록 단순화

운영 배포 (develop → main)

  • • 통합 테스트 완료 후 진행
  • • GitHub Actions CI/CD 통과 확인
  • • 병합 즉시 AWS 운영 서버 자동 배포

2. AWS SAM 로컬 개발 가이드

STEP 1. 소스 빌드 sam build

YAML 파일이나 소스 수정 시 필수 실행

STEP 2. 로컬 검증 sam local start-api

localhost:3000 환경에서 API 테스트

3. 표준 작업 흐름 (명령어 및 UI)

// 1. 로컬 작업 시작 (명령어)

git checkout develop

git pull origin develop # 최신 코드 가져오기

git checkout -b feature/task-name

// 2. SAM 빌드 및 테스트

sam build

sam local invoke # 또는 start-api

// 3. GitHub Push

git add .

git commit -m "feat: 기능 설명"

git push origin feature/task-name

// 4. feature → develop 병합 (GitHub UI에서 진행)

보호 브랜치이므로 터미널 직접 머지가 막혀 있습니다. 반드시 PR 페이지에서 진행합니다.

  • GitHub 접속 후 초록색 Compare & pull request 버튼을 클릭하여 PR 생성
  • Base: develop ← Compare: feature/* 확인! (main 선택 금지)
  • 리뷰어 1명 이상의 Approve 받기
  • 모든 리뷰 코멘트 해결 후 Squash and merge 클릭

// 5. develop → main 운영 배포 병합 (GitHub UI에서 진행)

통합 테스트 완료 시, 실제 서비스(Production) 자동 배포를 위해 진행합니다.

  • GitHub [Pull requests] 탭 → New pull request 클릭
  • Base: main ← Compare: develop 으로 설정
  • GitHub Actions(CI/CD) 상태 체크 통과 확인 (에러가 없어야 머지 가능)
  • 안전하게 Squash and merge 버튼을 눌러 실제 배포!

보안 및 절대 금지 사항 (Don'ts)

  • 로컬 main / develop 직접 Push
  • 리뷰 승인 없이 강제 병합(Force Merge)
  • AWS Access Key가 포함된 코드 커밋
  • 빌드/테스트 에러가 있는 상태로 PR 요청
문서 포털로 돌아가기

규칙을 준수하여 충돌 없는 평화로운 협업을 만들어 갑시다! 🚀