3.브랜치(Branch)

• 브랜치 모델: Git Flow, GitHub Flow 또는 Trunk Based Development 등의 브랜치 모델 중 하나를 선택해 일관된 브랜치 전략을 설정합니다.
  • Git Flow: 기능, 릴리스, 핫픽스 등의 작업을 각각의 브랜치에서 독립적으로 수행하고 점진적으로 병합합니다.
  • GitHub Flow: 특징이나 버그 수정을 위한 브랜치를 만들고, 완료되면 메인 브랜치에 병합합니다.
  • Trunk Based Development: 짧고 빈번한 브랜치를 생성해 작은 변경사항을 자주 병합합니다.
• 명명 규칙: 브랜치 이름에 대한 명명 규칙을 설정해 조직화합니다. 예를 들어, feature/login-system 또는 bugfix/collision-detection 등.

4. 코드 리뷰 및 병합 프로세스

• 풀 리퀘스트(PR) 정책: 모든 변경 사항은 PR을 통해 병합되도록 하고, PR 작성자는 동일한 규칙을 따르도록 합니다. PR에 대한 리뷰어를 지정하고 최소 리뷰어 수를 설정합니다.
• 자동화된 빌드 및 테스트: PR이 병합되기 전에 자동화된 빌드 및 테스트가 실행되도록 설정하여 변경 사항이 프로젝트에 문제를 일으키지 않도록 합니다.

7. 지속적인 통합(CI) 및 지속적인 배포(CD)

• CI/CD 파이프라인 설정: 팀이 각자의 브랜치에서 작업한 변경 사항을 빌드하고 테스트할 수 있도록 지속적 통합(Continuous Integration) 설정을 합니다. GitHub Actions, Jenkins, CircleCI, Travis CI 등을 사용할 수 있습니다.
• 자동 배포: 특정 브랜치(예: main 또는 production)에 변경 사항이 병합될 때 자동으로 배포될 수 있도록 설정합니다.

8. 주기적인 동기화 및 정리

• 정기적인 리포지토리 클린업: 오랜 기간 사용되지 않는 브랜치나 불필요한 파일들을 주기적으로 정리합니다.
• 리베이스 및 풀: 팀원들이 작업 도중 주기적으로 rebase와 pull을 사용해 최신 상태를 반영하도록 교육합니다.

클래스 헤더 파일(.h)

기본 형식 및 순서

1. Include Guards 또는 #pragma once: 중복 포함을 방지하기 위해 헤더 파일의 시작 부분에 포함합니다.
2. 필요한 Include 문: 클래스가 의존하는 다른 헤더 파일들을 포함합니다.
3. 전방 선언 (Forward Declarations): 필요한 경우 클래스 선언에 앞서 다른 클래스의 전방 선언을 합니다.
4. 클래스 선언:
   • 접근 제어자 (public, protected, private) 순서로 구성합니다.
   • 생성자 및 소멸자: 기본 생성자와 소멸자를 정의합니다.
   • public 멤버 함수: 외부에서 접근 가능한 함수 선언을 합니다.
   • protected 멤버 함수 및 변수: 서브클래스에서 접근할 수 있는 함수와 변수 선언을 합니다.
   • private 멤버 변수: 클래스 내부에서만 접근할 수 있는 변수 선언을 합니다.