콘텐츠로 건너뛰기

Git과 데이터 엔지니어링 초보자를 위한 버전 관리 가이드

GitHub을 사용한 버전 관리는 데이터 엔지니어링 프로젝트에서 협업을 체계적으로 관리하고 코드 품질을 유지하기 위해 필수적이다. 팀원들이 동일한 코드베이스에서 작업할 때, 수정 사항이 누락되거나 충돌하는 상황이 빈번히 발생할 수 있다. Git을 활용하면 이러한 문제를 최소화하고, 코드 변경 이력을 명확히 추적할 수 있다. 또한, 잘못된 코드 변경이 발생했을 때 신속히 이전 상태로 되돌아갈 수 있다는 점에서 매우 유용하다. 이 가이드는 Git과 버전 관리를 처음 접하는 나같은 초보자들을 위해 작성되었다. 🙂

Git은 코드 저장 및 협업 도구 중 가장 널리 사용되는 플랫폼인 GitHub와 함께 사용된다. GitHub를 사용하는 이유는 코드 변경 사항을 공유하고, 팀원들과 효율적으로 협업할 수 있는 다양한 기능(예: Pull Request, 코드 리뷰 등)을 제공하기 때문이다.

브랜치 네이밍 규칙과 관리 전략

브랜치 네이밍 규칙

브랜치 이름은 코드의 목적과 변경 유형을 명확히 나타내야 한다. 예시로 다음과 같은 네이밍 규칙이 있을 수 있다.

  • project/feature/name_of_feature: 새로운 기능 개발 시 사용한다.
  • project/fix/name_of_fix: 버그 수정 시 사용한다.
  • project/refactor/name_of_refactor: 코드 구조 변경 시 사용한다.

예를 들어, project_a에서 새로운 파이프라인 기능을 개발한다면 아래와 같이 브랜치를 생성한다:

git checkout -b project_a/feature/add_pipeline

브랜치 관리 전략

GitHub로 작업할 때, 프로젝트에는 두 가지 주요 브랜치가 있다:

  1. prod: 실제 운영 환경에서 사용되는 안정된 코드 브랜치이다.
  2. dev: 테스트와 개발 작업을 위한 브랜치이다.

새로운 기능 개발은 항상 prod 브랜치에서 시작하여, dev에서 테스트한 후 다시 prod로 병합한다.

브랜치 생성 과정

  1. prod에서 브랜치 생성:
    • git checkout 명령어는 현재 작업 중인 브랜치를 변경하거나 새 브랜치를 생성할 때 사용된다. git checkout prod는 prod 브랜치를 활성화하며, -b 옵션은 새로운 브랜치를 생성한다.아래 명령어로 prod 브랜치에서 새로운 작업 브랜치를 생성한다:
git checkout prod
git pull
git checkout -b feature/topic_1

2. 변경 사항 커밋 후 원격 저장소에 푸시:

  • 코드를 작성한 후 변경 사항을 저장소에 커밋한다.

git commit -am "Add new feature"
git push -u origin feature/topic_1

3. dev에서 병합 및 테스트:

  • Pull Request(PR)를 생성하여 dev에 병합한다.
  • 충돌이 발생하면 새로운 브랜치(feature/topic_1/dev)를 만들어 충돌을 해결한다.

4. prod로 배포:

  • dev에서 테스트가 완료되면, prod로 병합한다.

왜 항상 prod에서 시작해야 하는가?

prod 브랜치는 안정된 최신 코드가 포함되어 있다. 새로운 기능을 개발하거나 버그를 수정할 때는 안정된 코드를 기반으로 작업해야 예상치 못한 오류를 방지할 수 있다. 반면, dev 브랜치는 다양한 실험과 테스트 코드가 포함될 수 있어 예상치 못한 문제가 발생할 가능성이 크다. 따라서 새로운 작업을 시작할 때는 prod 브랜치에서 시작하는 것이 안전하다.

커밋과 Pull Request 작성 요령

커밋 작성 가이드

커밋 메시지는 명확하고 간결해야 하며, 다음과 같은 규칙을 따른다:

  • 명령형으로 작성: “이 커밋이 무엇을 할 것인가”를 나타낸다.
    • 예: add google analytics extraction pipeline
    • 예: fix bug surplus revenue
  • 작은 단위로 자주 커밋: 코드가 동작할 때마다 커밋하여 추적 가능성을 높인다.

Pull Request 작성 가이드

PR은 팀원들과 협업하고 변경 사항을 검토받기 위한 핵심 도구이다. 다음 사항을 포함하여 작성한다:

  1. 작업의 목적과 맥락:
    • 예: “이 PR은 ga 파이프라인을 추가합니다.”
  2. 관련 자료 링크:
    • 티켓 시스템을 사용한다면 해당 티켓 링크, dbt 문서, 관련 PR 링크
  3. 병합 및 배포 주의사항:
    • 전체 새로고침(full-refresh) 필요 여부
    • 모델 이름 변경 등
  4. 검토 및 병합 기준:
    • 최소 1명의 팀원 승인
    • 모든 테스트 통과

충돌 관리와 브랜치 정리

충돌 해결

PR 병합 시 dev와의 충돌이 발생할 수 있다. 이 경우 다음 단계를 따른다:

  1. dev 브랜치를 feature/topic_1에 병합:
git checkout feature/topic_1
git merge dev
  1. 새로운 브랜치 생성 후 충돌 해결:
git checkout -b feature/topic_1/dev
  1. 충돌 해결 후 dev로 병합한다.

브랜치 정리

작업이 완료된 브랜치는 삭제하여 코드베이스를 깔끔하게 유지한다:

  • 로컬 브랜치 삭제:
git branch -d feature/topic_1
  • 원격 브랜치 삭제:
git push origin --delete feature/topic_1

Version Control Guide 요약

  1. 새로운 브랜치 생성:
    • 항상 prod에서 시작한다.
  2. 변경 사항 커밋:
    • 로컬 저장소에 변경 사항을 저장한다:
  3. 작업 공유:
    • 원격 저장소에 업로드한다:
  4. dev에서 테스트:
    • PR 생성 후 dev에서 병합 및 테스트한다.
  5. prod로 배포:
    • 검증된 코드를 prod로 병합한다.
  6. 작업 완료 후 브랜치 삭제:
    • 로컬 및 원격 브랜치를 정리한다.

Git과 버전 관리를 올바르게 사용하면 데이터 엔지니어링 프로젝트에서 협업 효율성과 코드 품질을 동시에 높일 수 있다. 이 가이드를 바탕으로 Git의 기본 원칙을 익히고, 프로젝트에 적용해 보길 바란다.

관련 글(Related Posts)

태그: