[Git·GitOps 11] 팀 브랜치 전략과 Pull Request: merge·rebase의 선택

팀의 Git 규칙은 브랜치 이름보다 어떤 변경을 누가 검토하고 언제 합칠지를 정하는 데서 시작합니다. 두 사람이 쓰는 저장소에 복잡한 장기 브랜치 구조를 먼저 만들 필요는 없어요. 짧은 작업 브랜치, 자동 테스트, 보호된 main부터 구성해도 충분한 팀이 많습니다.

이 글은 원격 저장소와 Pull Request 또는 Merge Request 기능이 있는 서비스를 전제로 합니다. PR은 변경을 검토하고 합치도록 요청하는 서버 기능이며 Git 자체의 커밋 객체와는 다릅니다. 제품마다 명칭과 설정 화면은 달라도 판단할 내용은 비슷합니다.

Git·GitOps 전체 연재 · 11 / 24

이 글의 목차

작은 변경을 짧은 브랜치로 보낸다

git switch main
git pull --ff-only
git switch -c fix/empty-name
# Edit files and run tests.
git add greeting.py test_greeting.py
git diff --staged
git commit -m "Reject blank names in greeting"
git push -u origin fix/empty-name

실제로 수정한 파일만 add합니다. 아직 테스트 파일이 없다면 17편의 예제를 먼저 준비하거나 변경 대상에서 제외하세요. 서버에서 기준 브랜치 main을 선택해 PR을 만들고 문제, 수정 이유, 실행한 테스트를 적습니다.

리뷰어가 이해할 수 있는 단위가 좋은 PR의 크기입니다. 파일 수가 적어도 권한 모델을 바꾸면 검토가 클 수 있어요. 형식 변경과 기능 변경을 나누면 의도한 변경을 찾기 쉬워집니다.

trunk 기반과 Gitflow를 고르는 기준

흐름	맞는 상황	관리할 비용
짧은 브랜치 + main	자주 통합·배포하는 서비스	작은 변경, 빠른 테스트, 기능 플래그
Gitflow 계열	병행 지원 버전과 명시적 릴리스 준비	develop·release·hotfix 간 병합 관리
릴리스 브랜치	일부 버전만 유지보수	수정의 역전파·백포트 관리

trunk 기반 개발은 변경을 기준선에 자주 통합하는 접근입니다. PR을 쓰는 것과 충돌하는 개념이 아닙니다. 반대로 release 브랜치를 만들었다는 이유만으로 전체 Gitflow를 적용한 것은 아닙니다. 배포 주기, 지원 버전 수, 팀의 테스트 능력을 먼저 봅니다.

rebase는 변경을 새 부모 위에 다시 쌓는다

개인 작업 브랜치가 열린 동안 main이 바뀌었다면, 아직 공유하지 않은 커밋을 기준 위로 옮길 수 있습니다. 아래는 현재 작업 브랜치에서 실행합니다.

git status --porcelain
git fetch origin
git branch safety/before-rebase
git rebase origin/main
# If a conflict occurs: edit, git add, then git rebase --continue.
# To cancel an in-progress rebase: git rebase --abort.

rebase는 부모가 달라진 새 커밋을 만듭니다. 이미 다른 사람이 그 브랜치를 기반으로 작업 중이라면 기존 해시가 사라지는 변경을 함께 조율해야 합니다. 팀이 공유 브랜치의 rebase를 허용하지 않으면 merge로 최신 기준을 통합합니다.

내가 소유한 원격 작업 브랜치를 합의하에 재작성해야 한다면 --force-with-lease로 서버가 예상한 위치에 있는지 검사할 수 있습니다. 일반 --force보다 조건이 있지만 다른 사람의 작업을 무조건 보호해 주는 것은 아닙니다. 백그라운드 fetch로 추적 참조가 달라지는 환경도 고려해야 합니다.

# Only for your agreed, rewritable feature branch. Never use on shared main.
git push --force-with-lease origin HEAD:fix/empty-name

유지보수 브랜치로 수정 하나를 가져갈 때

운영 중인 이전 버전에 특정 버그 수정만 보내려면 cherry-pick을 사용할 수 있습니다. 기준 커밋의 변경을 현재 브랜치에 새 커밋으로 적용합니다. 아래는 이미 존재하는 유지보수 브랜치와 검토한 단일 수정 커밋이 있는 경우의 예시입니다.

git switch release/1.x
# Replace FIX_COMMIT with the reviewed fix commit ID.
git cherry-pick -x FIX_COMMIT

-x는 원본 커밋 정보를 메시지에 남깁니다. 새 브랜치의 의존성과 테스트를 확인하고 충돌 시 --continue 또는 --abort로 처리합니다. 커밋 하나가 앞선 여러 변경에 의존한다면 그것만 가져와서는 동작하지 않을 수 있어요. git cherry-pick의 적용 범위를 확인합니다.

서버에서 지켜야 할 규칙도 만든다

main에 직접 푸시를 제한하고, 필요한 리뷰와 CI 성공을 병합 조건으로 둡니다. CI가 도입되기 전부터 존재하지 않는 검사 이름을 필수로 걸면 모든 PR이 막힐 수 있으므로 실제 성공한 검사 이름을 확인하고 지정합니다. 관리자 예외와 긴급 변경 경로도 기록합니다.

승인된 PR도 병합 후 기준 브랜치에서 다시 확인할 필요가 있습니다. 두 PR이 각각 테스트에 성공해도 합친 조합은 실패할 수 있어요. 규모가 커지면 merge queue 같은 통합 검사를 검토할 수 있습니다.

Git의 재작성 동작은 git rebase, 서버의 제한은 Gitea 보호 브랜치 안내를 참고했습니다. 브랜치 전략은 하나를 외우기보다 변경이 운영으로 들어오는 경로를 설명할 수 있어야 합니다.

이전 글 · [Git·GitOps 10] 원격 저장소 연결하기: clone·fetch·pull·push · 다음 글 · [Git·GitOps 12] 태그와 릴리스: 배포한 커밋을 찾을 수 있게 만들기 · 연재 목록과 예제 파일