🐧 팀 빌딩 및 브랜치 전략

첫날 할 일

저장소 생성그라운드룰 정하기협업 방식 + 브랜치 전략 정하기README 최소 내용 작성

• 저장소 생성

  저장소 네이밍 컨벤션: 팀ID-프로젝트명(영문) (ex.소 web01-boostproject)

• 그라운드룰 정하기

  그라운드 룰

• 협업 방식 + 브랜치 전략 정하기

• README 최소 내용 작성

  • 팀원 소개
  • 협업 전략 (브랜치 구조와 분업하기, 의존적인 작업하기)
  • 그라운드룰 (최소한의 규칙, 무엇이 필요한가는 다같이 찾아보세요)
  • 기획/디자인 링크
  • 커밋 템플릿, 이슈 템플릿 : 개발 작업을 위한 공통 자료
  • 회의록/이슈/위키 연결 : 협업과 개발 과정의 문서 자료
  • 배포 링크가 있을 경우 해당 링크도 기술

브랜치⋅디렉토리 분리

의견 1 : client , server 디렉토리로 분리 FE , BE frontend , backend

의견 2 : FE BE 브랜치 각각 나누기

→ 둘 다 사용

frontend/login

FE/feat/story

BE/feat/signup

FE/fix/login

feat/login

• feature/card-input: 카드 입력 관련 기능 (1-1, 1-2)
• feature/message-transfer: 메시지 전송 관련 기능 (1-3, 1-4)
• feature/app-integration: 앱 연동 기능 (1-5)
• feature/server-response: 서버 응답 처리 (1-6, 1-7, 1-8)

FE/feat/story/task

Story 단위로 브랜치를 생성하고, 그 안에서 Task 단위 작업을 하위 브랜치나 커밋 단위로 관리하는 것도 좋은 방법입니다. 예를 들어 fe/feature/user-login 브랜치 내에서 작은 Task들을 커밋이나 추가 브랜치로 나눠서 작업하면 더 체계적으로 관리할 수 있습니다.

• 프론트와 백엔드가 feat/login 브랜치를 같이 쓴다면

• 프론트는 작업중인데 백엔드가 먼저 작업이 끝나서 PR 머지가 되면

• 프론트에 완료되지 않은 작업이 master 브랜치로 머지가 되는 문제

• 브랜치 전략 GPT 답변

  서버와 클라이언트를 분리해서 관리할 때는 각 폴더에 맞는 기능 개발과 변경 사항을 체계적으로 관리할 수 있는 Git 브랜치 전략이 필요합니다. 다음과 같은 방식이 효율적일 수 있습니다:

  1. 메인 브랜치 구분

  • main: 프로덕션에 배포할 최종 코드가 있는 안정된 브랜치로, 주로 릴리스 버전이 머지되는 곳입니다.
  • dev: 서버와 클라이언트 코드가 통합된 개발 브랜치입니다. 모든 기능 브랜치(feature branch)는 dev 브랜치로 머지된 후 테스트를 거칩니다.

  2. 기능별 브랜치 전략

  • 공통적인 변경 사항은 server/feature-<기능명> 또는 client/feature-<기능명> 형식으로 브랜치를 만듭니다. 예를 들어, 서버와 클라이언트 각각에 독립적으로 필요한 기능들을 따로 개발할 수 있습니다.
  • 서버와 클라이언트가 함께 업데이트되어야 하는 경우에는 feature/combined-<기능명> 형식으로 서버와 클라이언트 코드가 모두 포함된 브랜치를 만들어 dev에 머지합니다.

  3. 핫픽스 브랜치

  • 프로덕션에서 발생한 긴급한 버그를 수정해야 하는 경우 hotfix/issue-<버그명> 형식으로 브랜치를 나누고, 여기서 발생한 수정 사항을 main과 dev 브랜치에 동시에 병합합니다.

  4. 릴리스 브랜치

  • 릴리스 준비가 완료되면 release/<버전> 형식의 브랜치를 dev에서 분기하여, 안정화 과정을 거친 후 main으로 병합합니다. 필요시 배포 테스트 환경에 배포하는 것도 좋습니다.

  예시 브랜치 흐름

  1. server/feature-authentication, client/feature-authentication와 같이 분리된 기능 브랜치 생성
  2. 각각 기능을 개발한 후, dev 브랜치로 머지
  3. 모든 테스트와 통합 검증이 끝나면 release/1.0과 같이 릴리스 브랜치 생성 후 안정화
  4. 안정화가 완료되면 main 브랜치로 병합하여 배포

  이와 같은 전략은 서버와 클라이언트의 코드베이스를 명확히 분리하면서, 병합 충돌을 최소화하고 작업 흐름을 깔끔하게 유지할 수 있도록 돕습니다.