Cloud & DevOps

Git 고급 워크플로우 — 실무에서 바로 쓰는 전략

한 줄 요약: Git 고급 워크플로우의 핵심은 Interactive Rebase로 커밋 히스토리를 정리하고, Trunk-based Development로 브랜치 수명을 최소화하는 것이다. git add/commit/push를 넘어, 팀 협업에서 충돌을 줄이고 히스토리를 깔끔하게 유지하는 고급 Git 전략을 정리한다. GitHub Flow: 단순 (main + feature 브랜치).

by Lee발행: 2026-04-14

한 줄 요약: Git 고급 워크플로우의 핵심은 Interactive Rebase로 커밋 히스토리를 정리하고, Trunk-based Development로 브랜치 수명을 최소화하는 것이다.

git add/commit/push를 넘어, 팀 협업에서 충돌을 줄이고 히스토리를 깔끔하게 유지하는 고급 Git 전략을 정리한다. Trunk-based Development, Git Flow, Squash Merge 등의 장단점을 비교한다.

브랜치 전략 비교

GitHub Flow: 단순 (main + feature 브랜치). Git Flow: 체계적 (develop/release/hotfix). Trunk-Based: 빠른 배포 (짧은 feature 브랜치). 팀 규모와 배포 빈도에 따라 선택.

Interactive Rebase: git rebase -i HEAD~5로 최근 5개 커밋을 정리한다. 의미 없는 커밋('fix typo', 'wip')을 squash로 합치고, 커밋 메시지를 명확하게 수정한다. PR을 올리기 전에 히스토리를 정리하면 리뷰어가 변경 의도를 쉽게 파악할 수 있다.

유용한 Git 명령어 모음
# 커밋 히스토리 정리
git rebase -i HEAD~5

# 특정 커밋의 변경 내용 확인
git show abc123

# 변경사항을 임시 저장
git stash push -m "feature WIP"
git stash pop

# 다른 브랜치의 특정 커밋만 가져오기
git cherry-pick abc123

# 삭제된 브랜치 정리
git fetch --prune

브랜치 전략 비교: Trunk-based Development는 main 브랜치에 직접(또는 짧은 feature 브랜치로) 커밋하는 방식. CI/CD가 잘 갖춰진 팀에 적합하며, Google, Meta 등 대형 테크 기업이 사용한다. Git Flow는 develop/release/hotfix 브랜치를 사용하는 전통적 방식으로, 릴리스 주기가 긴 프로젝트에 적합하다.

rebase vs merge

merge: 이력이 그대로 보존, 머지 커밋 생성. rebase: 깔끔한 선형 이력, 하지만 강제 푸시 필요. 개인 브랜치는 rebase, 공유 브랜치는 merge가 안전합니다.

유용한 명령어

git stash — 작업 중 임시 저장
git cherry-pick — 특정 커밋만 가져오기
git bisect — 버그 도입 커밋 찾기
git reflog — 실수로 삭제한 것 복구

충돌 해결 전략

충돌을 줄이는 최선의 방법은 브랜치 수명을 짧게 유지하는 것이다. 하루 이상 유지되는 브랜치는 충돌 확률이 급격히 증가한다. 충돌이 발생하면 git merge --abort로 안전하게 취소하고, VS Code의 3-way merge 에디터로 시각적으로 해결하라.

팁: git rerere(reuse recorded resolution)를 활성화하면 이전에 해결한 충돌 패턴을 기억해 같은 충돌을 자동으로 해결한다. git config --global rerere.enabled true로 설정.

1인 개발자 관점에서 이 주제가 왜 중요한가

이 글의 주제(Git 고급 워크플로우 — 실무에서 바로 쓰는 전략)를 다룰 때 저는 버셀 + 깃허브 액션으로 자동 배포를 운영하는 입장 관점에서 봅니다. 단순히 새 기능을 소개하는 입장이 아니라, 12개 한국어 사이트를 1인으로 운영하면서 매일 클로드 코드를 켜두고 작업하는 입장이라 의사결정의 기준이 다소 좁고 실용적인 편입니다. 신기술이 출시될 때마다 곧바로 도입하기보다는 우선 한두 사이트에 시범 도입해 두고, 운영 부담이 늘지 않는지 며칠 지켜본 뒤 전체 확산을 결정하는 식입니다.

가장 자주 보는 변수는 한국 결제 시 VAT 10% 환급 절차, 그리고 12개 사이트를 동시에 운영할 때 변수 분리 비용입니다. 두 변수는 신기술을 도입할지 말지 결정할 때 거의 매번 영향을 줍니다. 글의 본문은 위의 두 축을 직접 명시하지는 않지만, 본문에서 다루는 항목을 이 축에 비춰 보시면 본인 환경에 맞는지 빠르게 판단할 수 있습니다. 특히 1인 개발자의 현금흐름 한계 같은 운영 변수는 도구 자체 성능보다 더 큰 영향을 주는 경우가 많기 때문에 본문 비교표를 볼 때 같이 떠올리시면 좋습니다.

한 가지 더 강조하면, Cloud & DevOps 영역의 글을 읽을 때 저는 본문이 다루는 도구·서비스가 ① 한국 결제 가능 여부 ② 한국어 응답 품질 ③ 종량제 비용의 예측 가능성 ④ 1인 개발자 학습 시간 대비 효과, 네 항목을 모두 충족해야 실제 도입을 결정합니다. 네 항목 중 하나라도 명확하지 않으면 도입을 1~2주 미루는 편이고, 그 사이 같은 카테고리의 다른 글도 확인합니다.

본문의 각 비교·코드·체크리스트는 이 네 항목 중 어느 부분에 영향을 주는지 의식하면서 보시면 더 빠르게 결론에 도달하실 수 있습니다. 본 사이트의 다른 Cloud & DevOps 글과 함께 보시면 같은 평가 축이 반복되는 것을 확인하실 수 있습니다. 토픽 페이지 또는 같은 카테고리 태그를 따라가시면 동일한 평가 기준이 적용된 글을 한 번에 모아 보실 수 있습니다.

본인 환경에 적용하기 전 확인할 체크포인트

본문의 내용을 본인 환경에 적용하기 전에 다음 항목을 빠르게 확인하시면 도입 실패 가능성을 줄일 수 있습니다.

공식 문서 버전 일치 — 본문 작성 시점과 현재 배포 버전이 다른 경우, 같은 명령어가 다르게 동작할 수 있습니다.
한국 결제·환율 검증 — 카드 결제, 부가가치세 처리, 원화 환산 시점에 따라 실제 청구액이 본문 예시와 다를 수 있습니다.
기존 스택과의 호환성 — Next.js·Vercel·Supabase 같은 기본 스택과 충돌이 없는지 패키지 의존성을 먼저 확인하세요.
롤백 절차 사전 정리 — 도입 후 문제가 생겼을 때 1회 명령으로 이전 상태로 되돌릴 수 있는 절차를 도입 전에 메모해 두시면 운영 부담이 크게 줄어듭니다.

위 네 항목을 모두 통과하면 보통 1~2시간 내에 도입을 마칠 수 있고, 통과하지 못한 항목이 있다면 그 항목을 우선 해결한 뒤 다시 시작하는 것이 효율적입니다.

자주 묻는 질문

Git 고급 워크플로우, 한 줄로 정리하면 어떻게 되나요?

git add/commit/push를 넘어, 충돌을 줄이고 히스토리를 깔끔하게 유지하는 운영 기술입니다. 핵심은 두 가지로 압축됩니다. 하나는 브랜치 수명을 짧게 가져가는 것(Trunk-based Development)으로, 하루 이상 묵힌 브랜치일수록 충돌 확률이 급격히 올라가기 때문입니다. 다른 하나는 PR을 올리기 전 git rebase -i로 의미 없는 wip 커밋을 squash해 리뷰어가 변경 의도를 한눈에 파악하게 만드는 것입니다. 단, rebase는 아직 공유되지 않은 개인 브랜치에만 쓰고 공유 브랜치는 merge로 가야 안전하다는 원칙만 지키면 됩니다.

실무에서 처음 도입할 때 가장 먼저 확인할 것은 무엇인가요?

팀이 공유하는 브랜치에 이미 푸시된 커밋을 rebase 하지 않는지부터 확인하세요. 본문에서 정리했듯 개인 브랜치는 rebase, 공유 브랜치는 merge가 안전합니다. 공유 이력을 rebase 하고 force push 하면 동료의 로컬 히스토리가 어긋나 충돌이 폭증합니다. 도입 순서로는 먼저 git config --global rerere.enabled true 로 충돌 재사용을 켜고, git rebase -i 는 아직 푸시하지 않은 로컬 커밋에만 적용하는 규칙을 팀과 합의한 뒤 시작하시길 권합니다. 만약 rebase 도중 꼬이면 git rebase --abort 로 즉시 원상복구되니 부담 없이 연습할 수 있습니다.

가장 자주 발생하는 실수나 함정은 무엇인가요?

가장 흔한 사고는 이미 공유한 브랜치를 rebase 한 뒤 git push --force 로 덮어쓰는 것입니다. 같은 브랜치를 쓰던 동료의 커밋이 사라지거나 중복되어 복구에 한참 걸립니다. 꼭 강제 푸시가 필요하면 --force 대신 --force-with-lease 를 쓰면 그 사이 올라온 남의 커밋을 덮어쓸 때 거부되어 안전합니다. 두 번째 함정은 squash 로 커밋을 합칠 때 의미 있는 단위까지 뭉개버려 나중에 git bisect 로 버그 도입 지점을 찾기 어려워지는 경우입니다. 실수로 커밋이나 브랜치를 날렸다면 git reflog 에 30일가량 기록이 남아 있으니 거기서 해당 해시를 찾아 복구하시면 됩니다.

다른 대안과 비교했을 때 어떤 상황에 적합한가요?

여기서 비교 대상은 결국 브랜치 전략입니다. CI/CD가 잘 갖춰져 있고 하루에도 여러 번 배포하는 팀이라면 Trunk-based Development가 가장 잘 맞습니다. main에 짧은 feature 브랜치로 빠르게 합치는 방식이라 충돌이 적고 구글·메타 같은 대형 조직이 채택한 방식입니다. 반대로 릴리스 주기가 길고 여러 버전을 동시에 유지·핫픽스해야 하는 프로젝트(예: 설치형 소프트웨어)라면 develop/release/hotfix를 나누는 Git Flow가 더 안전합니다. 그 중간에서 main + feature 브랜치만으로 단순하게 가고 싶다면 GitHub Flow가 무난합니다. 혼자 운영하는 저장소라면 굳이 Git Flow까지 갈 필요 없이 GitHub Flow나 trunk 방식으로 가볍게 가는 편이 낫습니다.

더 깊게 공부하려면 어떤 자료를 보면 좋을까요?

개념을 탄탄히 잡고 싶다면 무료 전자책인 Pro Git(git-scm.com/book)이 정석입니다. 특히 Rewriting History 챕터에서 interactive rebase와 squash를, Distributed Workflows 챕터에서 브랜치 전략을 그림과 함께 깊게 다룹니다. 키워드로는 git reflog(실수 복구)와 git bisect(버그 도입 커밋 이진 탐색) 두 명령을 꼭 손으로 연습해 보시길 권합니다. 둘 다 평소엔 안 쓰다가 사고가 났을 때 진가를 발휘합니다. 그리고 trunkbaseddevelopment.com에서 트렁크 기반 개발의 전제 조건과 패턴을 읽어 두면 본문의 브랜치 전략 비교가 한층 또렷해집니다.

git브랜치rebase워크플로우협업