[git] subbranch

-·7일 전

github

목록 보기
6/6

1. 일반적인 흐름

[Root] -> main
         |
         +-- [main에서 딴 브랜치] feat/new_feature
              |
              +-- [feat/new_feature에서 딴 브랜치] feat/new_feature_subtask_1
                   |
                   +-- [feat/new_feature_subtask_1에서 딴 브랜치] feat/new_feature_subtask_1_refactor
  • main: 프로젝트의 기본 줄기.
  • feat/new_feature: main에서 새로운 기능을 만들기 위해 딴 브랜치.
  • feat/new_feature_subtask_1: feat/new_feature 브랜치에서 작업하던 중, 더 작은 단위의 작업(subtask_1)을 위해 다시 딴 브랜치.
  • feat/new_feature_subtask_1_refactor: feat/new_feature_subtask_1 브랜치의 코드를 리팩토링(개선)하기 위해 또 딴 브랜치.

2. 왜 이렇게 할까?

  1. 작업 분담 및 집중:
    • 큰 기능(feat/new_feature)을 여러 사람이 나눠서 작업할 때, 각자 서브 브랜치를 따서 맡은 부분만 집중해서 작업할 수 있음.
  2. 단계별 관리:
    • 어떤 작업은 "아이디어 구상" 단계, "기본 코드 작성" 단계, "테스트 코드 작성" 단계 등으로 나눌 수 있습니다. 각 단계를 브랜치로 관리하면 진행 상황을 명확히 파악하기 좋음.
  3. 실험 및 위험 작업:
    • 매우 실험적인 기능이나, 코드를 크게 변경해야 하는 작업은 main이나 다른 중요한 브랜치에서 직접 하기 위험합니다. 이때는 독립적인 브랜치를 따서 마음껏 실험해볼 수 있음. 실패하면 그냥 버리면 그만.
  4. 코드 리뷰 효율화:
    • PR(Pull Request)을 올릴 때, 너무 길고 복잡한 PR보다는 작고 명확한 단위의 PR이 검토하기 훨씬 쉬움. 서브 브랜치를 통해 작업을 나누면 PR도 작게 만들 수 있음.

3. 따는 방법

기존 브랜치에서 브랜치를 따는 방법은 동일.

# 현재 브랜치가 'feat/new_feature' 라고 가정

# 1. 새 브랜치 생성 및 이동
git checkout -b feat/new_feature_subtask_1

# 또는, 이미 다른 브랜치에 있어도 기준이 되는 브랜치에서 딸 수 있음.
# git checkout feat/new_feature (기준이 되는 브랜치로 이동)
# git checkout -b feat/new_feature_subtask_1 (거기서 따기)
profile
살아남은 자가 강한 것

0개의 댓글