Apache Airflow에 기여하다 보면, main 브랜치에 머지된 변경사항을 다음 릴리스 브랜치에 반영해야 하는 상황이 종종 발생합니다.
즉, main에 머지되었다고 끝이 아니라, 릴리스 대상 브랜치(예: v3-1-test)에도 동일한 변경을 반영해야 합니다. 이 과정을 Backport라고 합니다.
저 역시 커미터가 되어 릴리스 관리를 하기 전까지는 이 흐름을 잘 몰랐습니다.
(사실 저도 한 번 실수하고 나서 제대로 이해하게 되었습니다
)
이 글에서는 v3-1-test 브랜치로 Backport 하는 방법을 정리해보겠습니다.
전체 흐름 요약
v3-1-test기반으로 backport 브랜치 생성main에 머지된 커밋을 cherry-pick- 충돌 해결
- 원격 브랜치에 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 브랜치에 머지됩니다.
따라서:
- GitHub에서
main에 머지된 커밋으로 이동
- Full SHA 값을 복사
- 아래 명령어로 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 과정이 처음에는 복잡하긴 합니다.
하지만 직접 해보고 나면 흐름이 명확해지는 것 같습니다.
특히 커미터가 되면 릴리스 브랜치 관리가 중요해지기 때문에
이 과정을 정확히 이해하는 것이 큰 도움이 되는 것 같습니다.


