Apache Airflow 릴리스 브랜치에 Backport 하는 법

Apache Airflow에 기여하다 보면, main 브랜치에 머지된 변경사항을 다음 릴리스 브랜치에 반영해야 하는 상황이 종종 발생합니다.

즉, main에 머지되었다고 끝이 아니라, 릴리스 대상 브랜치(예: v3-1-test)에도 동일한 변경을 반영해야 합니다. 이 과정을 Backport라고 합니다.

저 역시 커미터가 되어 릴리스 관리를 하기 전까지는 이 흐름을 잘 몰랐습니다.
(사실 저도 한 번 실수하고 나서 제대로 이해하게 되었습니다 :sweat_smile:)

이 글에서는 v3-1-test 브랜치로 Backport 하는 방법을 정리해보겠습니다.

전체 흐름 요약

  1. v3-1-test 기반으로 backport 브랜치 생성
  2. main에 머지된 커밋을 cherry-pick
  3. 충돌 해결
  4. 원격 브랜치에 push 후 PR 생성

1. v3-1-test 브랜치 기반으로 backport 브랜치 생성

먼저 upstream 저장소 기준으로 v3-1-test 브랜치를 가져옵니다.

git checkout -b backport-<PR번호>-v3-1-test upstream/v3-1-test

PR 제목은 다음처럼 작성합니다:

[v3-1-test] PR 제목

2. merge 커밋 cherry-pick

Airflow는 기본적으로 Squash Merge 전략을 사용합니다.
즉, 여러 커밋이 하나의 커밋으로 합쳐져 main 브랜치에 머지됩니다.

따라서:

  1. GitHub에서 main에 머지된 커밋으로 이동
  2. Full SHA 값을 복사
  3. 아래 명령어로 cherry-pick
git cherry-pick <복사한 full SHA>

3. 충돌해결

깔끔하게 cherry-pick이 되면 좋겠지만, 이 단계에서 충돌이 발생하는 경우가 많습니다.

왜냐하면 main에는 이미 들어간 변경사항이 v3-1-test에는 아직 반영되지 않은 경우가 있기 때문입니다.

이때 선택지는 두 가지입니다.

의존 PR까지 함께 Backport

  • 영향이 적고
  • 작업량이 크지 않다면

관련 PR도 함께 backport할 수 있습니다.

단, 이 경우 반드시 다른 커미터나 릴리스 매니저와 논의 후 진행하는 것이 좋습니다.

충돌 부분만 수정

대부분은 이 경우입니다.

  • main에만 존재하는 대규모 리팩토링
  • 릴리스 브랜치에 포함되면 위험한 변경

이런 경우에는 충돌 부분만 릴리스 브랜치에 맞게 수정합니다.

충돌을 해결한 후:

git cherry-pick --continue

로 커밋을 완료합니다.

4. 로컬 브랜치에 push

git push -u origin backport-<PR 번호>-v3-1-test

이후 GitHub에서:

  • Base: v3-1-test
  • Compare: backport-<PR번호>-v3-1-test
    으로 PR을 생성합니다.

제목은 다음 형식을 유지합니다:

[v3-1-test] PR 제목

마무리

Backport 과정이 처음에는 복잡하긴 합니다.
하지만 직접 해보고 나면 흐름이 명확해지는 것 같습니다.

특히 커미터가 되면 릴리스 브랜치 관리가 중요해지기 때문에
이 과정을 정확히 이해하는 것이 큰 도움이 되는 것 같습니다.

1개의 좋아요