Jira 티켓 하나로 브랜치를 파서 1차 작업을 끝내고 이미 dev·main에 배포까지 했는데, 같은 티켓과 관련된 추가 수정 사항이 뒤늦게 생기는 상황, 실무에서 정말 자주 마주칩니다. 이때 git hotfix 브랜치 후속 수정(git 브랜치 재사용)을 어떻게 처리해야 fetch·pull·rebase가 꼬이지 않는지가 이번 글의 주제입니다.
저희 팀도 실제로 이 상황을 겪으면서, merge 방식(squash인지 merge commit인지)에 따라 대응법이 완전히 달라진다는 걸 확인했습니다. 이 글에서는 상황별로 rebase, reset, cherry-pick 중 무엇을 써야 하는지 명령어 기준으로 정리합니다.
“같은 브랜치를 이어 써도 되는지”부터, “이미 새 작업을 시작한 상태라면 어떻게 하는지”까지 순서대로 다룹니다.
📌 한눈에 보는 후속 수정 대응 핵심
이미 배포된 브랜치의 후속 수정은 merge 방식(squash/merge commit), 작업 진행 상태(미커밋/커밋완료)에 따라 rebase·reset·cherry-pick 중 하나를 골라야 하는 상황입니다.
이미 배포한 브랜치를 그대로 이어 써도 될까?
“쓰던 브랜치에 커밋만 더 얹으면 되지 않나?” 싶지만, 여기서 히스토리가 꼬이기 시작합니다. 문제는 merge 방식에 따라 정답이 갈린다는 점입니다.
Merge commit을 쓴다면 A의 원래 커밋들이 dev 히스토리에 그대로 남아있기 때문에, rebase만 하면 git이 “이미 dev에 들어간 커밋”을 자동으로 스킵해줍니다.
git checkout A git fetch origin git rebase origin/dev
반면 squash merge를 쓴다면 A의 여러 커밋이 dev 쪽에서 하나로 합쳐지기 때문에, git 입장에서는 A의 원래 커밋과 dev의 squash 커밋이 서로 다른 커밋으로 보입니다. 이 상태에서 rebase하면 이미 반영된 내용을 다시 적용하려다 충돌이 납니다. 이럴 땐 rebase 대신 A 브랜치 자체를 최신 dev로 맞춰버리는 게 깔끔합니다.
git checkout A git fetch origin git reset --hard origin/dev
A의 예전 커밋은 이미 dev(그리고 main)에 안전하게 들어가 있으니, 로컬 A 브랜치에서 리셋해도 내용이 사라지는 게 아닙니다. 원격에 이미 push된 브랜치라면 리셋 후 git push --force-with-lease origin A로 강제 push하면 됩니다. 팀원이 같은 브랜치를 보고 있지 않은지만 확인하고 쓰세요.
📊 Merge 방식별 대응법
Merge commit → fetch 후 rebase origin/dev (자동 스킵)
Squash merge → fetch 후 reset –hard origin/dev (브랜치를 최신 dev로 맞춤)
이미 A 브랜치에서 새 작업 중이었다면 어떻게 할까?
squash merge 환경에서 reset을 그대로 쓰면 문제가 되는 경우가 있습니다. 후속 수정 작업을 이미 시작한 상태라면요. 이때는 어디까지 진행됐는지에 따라 두 가지로 나뉩니다.
📎 상황 1 — 아직 커밋 안 한 변경사항만 있는 경우
git stash git fetch origin git reset --hard origin/dev git stash pop
작업 중이던 변경사항을 잠시 치워두고(stash) 브랜치를 최신 dev로 맞춘 다음, 다시 꺼내옵니다. 이전 커밋 내용과 겹치는 부분이 없다면 충돌 없이 그대로 적용됩니다.
📎 상황 2 — 새 작업을 이미 커밋까지 해둔 경우
이때는 새로 쌓은 커밋만 골라서 최신 dev 위로 옮기는 cherry-pick이 안전합니다.
git log A # 새로 작업한 커밋 해시 확인 (예: C1, C2) git checkout -b A-new origin/dev git cherry-pick C1 C2
여기서 C1, C2는 후속 작업으로 새로 쌓은 커밋만 해당하고, squash로 이미 dev에 들어간 예전 커밋은 포함하지 않습니다. 어떤 커밋이 새 커밋인지 헷갈릴 땐 아래 명령으로 dev에는 없고 A에만 있는 커밋만 뽑아보면 됩니다.
git log --oneline origin/dev..A
정리는 이렇게 마무리합니다.
git branch -D A git branch -m A-new A git push origin A --force-with-lease
📊 상황별 대응 요약
Merge commit + 처음부터 → fetch 후 rebase origin/dev
Squash merge + 처음부터 → fetch 후 reset –hard origin/dev
Squash merge + 미커밋 작업 있음 → stash → reset –hard → stash pop
Squash merge + 커밋까지 완료 → 새 커밋만 cherry-pick해서 새 브랜치로 이전
fetch·pull·rebase가 꼬이지 않게 하는 습관
가장 확실한 방법은 순서를 습관화하는 것입니다. 새 작업을 시작하기 전에는 항상 git fetch origin → git checkout -b JIRA-123-2 origin/dev 순으로 최신 dev를 기준으로 브랜치를 파고 시작합니다. 작업 도중 dev가 앞서 나갔다면 git fetch origin 후 git rebase origin/dev로 맞춰주는 편이, git pull(기본 merge)을 반복해서 merge 커밋이 쌓이는 것보다 히스토리가 깔끔합니다.
실제로 이 순서(fetch → 새 브랜치 → 작업 중 주기적 rebase)를 지키면서 느낀 건, 충돌은 대부분 “오래 묵힌 브랜치를 뒤늦게 맞추려 할 때” 터진다는 점입니다. 하루이틀 안에 rebase를 자주 해서 작은 충돌을 그때그때 처리하면, 나중에 PR 올릴 때 큰 충돌을 만날 일이 거의 없습니다.
📱 후속 수정, 새 브랜치 vs 기존 브랜치
1차 PR이 squash merge로 이미 dev에 반영됐다면 → 최신 dev에서 새 브랜치를 파는 것을 권장합니다.
아직 dev에 반영 전(PR 진행 중)이라면 → 기존 브랜치에 커밋을 이어서 추가해도 무방합니다.
브랜치 이름은 같은 티켓 번호를 유지하되 뒤에 구분자(JIRA-123-2 등)를 붙이면 추적성도 그대로 살릴 수 있습니다.
개인적으로는 squash merge를 쓰기로 한 이상, “같은 브랜치를 계속 재사용한다”는 감각 자체를 버리는 게 편합니다. 브랜치는 늘 최신 dev에서 새로 파고, 남겨야 할 건 커밋이 아니라 Jira 티켓 번호와 작업 맥락뿐이라고 생각하면 혼란이 훨씬 줄어듭니다.
squash merge와 merge commit을 왜 구간마다 다르게 쓰는지 궁금하다면
Squash Merge vs Merge Commit 완전 정리 보러가기 →🧾 정리하며
이미 배포된 브랜치의 후속 수정은 merge 방식과 작업 진행 상태, 두 가지 축으로만 판단하면 됩니다. merge commit이면 rebase, squash merge면 reset — 그리고 이미 작업 중이었다면 stash 또는 cherry-pick으로 새 작업분만 살려서 최신 dev 위로 옮기면 충돌 없이 깔끔하게 이어갈 수 있습니다.
FAQ — 후속 수정 브랜치 처리 자주 묻는 질문
Q1. 이미 배포된 Jira 브랜치에 후속 수정이 생기면 어떻게 하나요?
1차 PR이 squash merge로 이미 dev에 반영됐다면 기존 브랜치에 이어서 작업하지 말고, 최신 dev 기준으로 새 브랜치(예: JIRA-123-2)를 파는 것이 안전합니다.
Q2. Merge commit과 Squash merge에서 같은 브랜치를 이어 쓰는 방법이 다른가요?
Merge commit이라면 fetch 후 rebase origin/dev로 자동 스킵되지만, squash merge라면 rebase 대신 fetch 후 reset –hard origin/dev로 브랜치를 최신 dev에 맞추는 방식이 안전합니다.
Q3. 이미 새 작업을 진행 중인데 브랜치를 최신 dev로 맞춰야 하면 어떻게 하나요?
아직 커밋 전이라면 stash로 변경사항을 잠시 치워두고 reset 후 다시 꺼내오면 되고, 이미 커밋까지 했다면 새 커밋만 cherry-pick으로 최신 dev 기준의 새 브랜치로 옮기는 것이 안전합니다.
Q4. cherry-pick할 커밋을 어떻게 골라내나요?
git log –oneline origin/dev..A 명령으로 dev에는 없고 해당 브랜치에만 있는 커밋만 뽑아보면, 그게 곧 cherry-pick 대상 목록입니다.
Q5. fetch, pull, rebase가 꼬이지 않게 하려면 어떤 습관이 필요한가요?
새 작업 시작 전엔 항상 fetch 후 최신 dev 기준으로 브랜치를 파고, 작업 도중에는 pull(기본 merge) 대신 fetch + rebase로 주기적으로 맞춰주는 게 히스토리를 깔끔하게 유지하는 방법입니다.
Q6. reset –hard 후 원격 브랜치에 다시 push하려면 어떻게 하나요?
git push –force-with-lease origin A로 강제 push하면 됩니다. 다만 다른 팀원이 같은 브랜치를 보고 있지 않은지 먼저 확인해야 합니다.
