A-7: rebase와 히스토리 재작성

또 만났네요, 홍순구 튜터입니다. 지난 시간 우리는 팀의 협업 약속인 브랜치 전략 세 가지를 구분하고, 남의 공개 저장소에 fork 와 두 원격으로 기여하는 한 바퀴까지 돌려봤어요. 그 끝에서 fork 동기화를 할 때, 원본의 최신 변경을 내 브랜치에 합치려고 merge 를 썼던 거 기억하세요?

그런데 제가 그때 슬쩍 흘린 말이 있어요. "합치는 방법이 merge 만 있는 게 아니다" 라고요. 그리고 더 거슬러 올라가면, GitHub 가 PR 을 버튼으로 합쳐줄 때 합치는 방식 중에 "Rebase" 라는 게 있었죠. 오늘은 그 rebase(리베이스) 를 드디어 직접 손으로 다뤄요. merge 와 rebase 가 커밋의 역사를 어떻게 다르게 만드는지 나란히 놓고 보고, 지저분하게 쌓인 커밋을 깔끔하게 정리하는 법까지 배웁니다.

솔직히 말할게요. 오늘은 이 과목에서 처음으로 난이도가 한 단계 올라가는 시간이에요. rebase, cherry-pick, squash, force-push... 단어부터 좀 무섭게 들리죠? 현업 신입도 "rebase 하랬는데 그게 뭐죠" 하고 식은땀 흘리는 단골 주제예요. 그런데 걱정 마세요. 이름만 낯설지, 하나씩 천천히 보면 전부 "커밋을 옮기고 정리하는" 단순한 일이에요. 게다가 오늘 배울 모든 작업은 망쳐도 되돌릴 수 있어요. A-3 에서 배운 reflog 라는 안전망이 든든하게 받쳐주거든요. 그러니 안심하고 하나씩 가봅시다.

   오늘의 여정 — 커밋의 역사를 다시 쓰는 법

   ① 합치는 길은 두 갈래         — merge vs rebase
   ② 가지를 옮겨 한 줄로          — git rebase
   ③ rebase 도중 멈췄을 때        — 충돌 해결
   ④ 커밋을 편집하는 화면         — rebase -i 기초
   ⑤ 지저분한 커밋을 깔끔히       — squash·fixup·reword
   ⑥ 그 커밋 하나만 가져올게      — cherry-pick
   ⑦ 절대 건드리면 안 되는 선     — rebase 황금률
   ⑧ 부득이할 땐 안전하게         — push --force-with-lease

①②③에서 rebase 가 무엇이고 어떻게 쓰는지, 도중에 멈추면 어떻게 빠져나오는지를 직접 익혀요. ④⑤에서 여러 커밋을 골라 합치고 다듬는 인터랙티브 rebase 를 다루고, ⑥에서 특정 커밋만 콕 집어 가져오는 cherry-pick 을 봐요. 마지막 ⑦⑧에서 "역사를 고쳐 쓰는 일" 의 안전 수칙 — 황금률과 안전한 강제 push — 을 짚으며 협업 git 의 마지막 고급 조각을 채웁니다.

💡 오늘 수업의 핵심 — "merge 는 합친 흔적을 남겨 역사를 사실 그대로 보존하고, rebase 는 가지를 옮겨 역사를 한 줄로 깔끔하게 고쳐 쓴다. rebase -i 로 지저분한 커밋을 합치고 다듬으며 cherry-pick 으로 특정 커밋만 가져올 수 있다. 단 역사를 고쳐 쓰는 일이라, 남과 공유한 브랜치는 절대 rebase 하지 않는다는 황금률을 지키고, 부득이할 땐 --force-with-lease 로 안전하게 push 한다."

🎯 학습 목표

• merge 와 rebase 가 커밋의 역사를 어떻게 다르게 만드는지 다이어그램으로 구분하고, 언제 무엇을 쓸지 판단합니다.
• 인터랙티브 rebase(rebase -i) 로 지저분한 커밋을 합치고 다듬으며, cherry-pick 으로 특정 커밋만 골라 가져옵니다.
• 역사를 고쳐 쓰는 일의 안전 수칙 — rebase 황금률 과 git push --force-with-lease — 을 이해하고, 망쳐도 reflog 로 되돌릴 수 있다는 안전망을 갖춥니다.

Step 1: "합치는 길은 두 갈래 — merge vs rebase"

두 브랜치를 합치는 방법은 사실 두 가지예요. 하나는 우리가 이미 잘 아는 merge, 다른 하나가 오늘의 주인공 rebase 예요. 둘 다 "갈라진 가지를 다시 하나로 모은다" 는 목적은 같은데, 합친 뒤의 역사 모양이 완전히 달라요. 이 차이를 그림으로 먼저 눈에 익히는 게 오늘의 출발점이에요.

상황을 하나 그려볼게요. main 에서 feature 브랜치를 따서 D, E 두 커밋을 작업하는 동안, 다른 동료가 main 에 C 커밋을 올려서 main 이 앞서갔어요. 이제 내 feature 작업을 main 에 모아야 합니다.

먼저 우리가 아는 merge 방식이에요. merge 는 두 갈래를 묶는 새 커밋(병합 커밋 M) 을 하나 만들어요. "여기서 두 갈래가 만났다" 는 흔적을 역사에 그대로 남기는 거예요.

   merge — 합친 흔적(병합 커밋 M)을 남긴다. 갈래가 그대로 보인다.

   main      A───B───C───────M
                  \         /
   feature         D───E───┘
                            └ M = 두 갈래가 만난 병합 커밋

다음은 오늘 배울 rebase 방식이에요. rebase 는 병합 커밋을 만들지 않아요. 대신 내 feature 의 커밋 D, E 를 떼어다가 main 의 맨 끝(C 뒤)으로 옮겨 붙여요. 그러면 갈래가 사라지고 역사가 한 줄로 쭉 펴져요.

   rebase — D·E를 main 끝으로 옮겨 한 줄로 편다. 깔끔하지만 역사를 고쳐 쓴다.

   main      A───B───C───D'───E'
                          └ D·E가 C 뒤로 옮겨지며 새 커밋 D'·E'로 다시 쓰인다

여기서 한 가지 중요한 걸 짚을게요. 옮겨진 커밋이 D, E 가 아니라 D', E'(프라임) 로 표시된 거 보이세요? rebase 는 커밋을 단순히 이사시키는 게 아니라, 옮겨 붙이면서 완전히 새로운 커밋으로 다시 만들어요. 내용은 같아도 커밋의 고유 이름표(해시)가 바뀌는 거예요. 바로 이게 "역사를 고쳐 쓴다" 는 말의 진짜 의미이고, 오늘 후반부 황금률의 씨앗이에요.

그럼 둘 중 뭘 써야 할까요? 정답은 "상황에 따라 다르다" 예요.

⚠️ rebase 는 역사를 한 줄로 펴주는 매력적인 도구지만, 커밋을 새로 만든다(해시가 바뀐다) 는 점이 양날의 검이에요. 내 손 안에서 아직 남과 공유 안 한 커밋이면 마음껏 정리해도 되지만, 이미 남과 나눈 커밋을 rebase 하면 동료의 저장소와 엉켜요. 그래서 "언제 rebase 를 쓰면 안 되는지" 를 정하는 황금률을 오늘 Step 7 에서 꼭 정해둘 거예요.

💡 한 줄 정리

브랜치를 합치는 길은 두 갈래다. merge 는 병합 커밋을 남겨 갈래를 사실 그대로 보존하고, rebase 는 내 커밋을 상대 브랜치 끝으로 옮겨 붙여 역사를 한 줄로 깔끔하게 편다. 단 rebase 는 옮기면서 커밋을 새로 만들어(해시가 바뀐다) 역사를 고쳐 쓴다.

Step 2: "가지를 옮겨 한 줄로 — git rebase"

이제 직접 손으로 rebase 를 해봐요. Step 1 의 그 상황 그대로예요. 내가 feature 브랜치에서 작업하는 동안 main 이 앞서간 상태에서, 내 작업을 main 의 최신 위로 옮겨 붙일 거예요.

먼저 지금 역사가 어떻게 갈라져 있는지 봅시다. git log 에 --oneline --graph --all 을 붙이면 커밋 그래프를 터미널에서 직접 볼 수 있어요.

git switch feature
git log --oneline --graph --all
# * 3c4d5e6 (main) 동료가 올린 변경      ← main이 앞서감
# | * a1b2c3d (HEAD -> feature) 내 작업 E
# | * f6e5d4c 내 작업 D
# |/
# * 9a8b7c6 공통 조상 커밋

갈래가 보이죠? 이제 feature 브랜치에 선 채로 git rebase main 을 하면, 내 커밋 D, E 를 main 의 맨 끝으로 옮겨 붙여요.

git rebase main
# Successfully rebased and updated refs/heads/feature.

이 한 줄이 뜨면 성공이에요. 다시 그래프를 보면, 갈래가 사라지고 내 커밋이 main 뒤로 쭉 펴진 게 보여요.

   rebase 전 — 갈래로 나뉨            rebase 후 — 한 줄로 펴짐

   main    ●───●───● (C)             main    ●───●───● (C)
            \                                         \
   feature   ●───● (D·E)             feature           ●───● (D'·E')
                                              └ 내 작업이 main 최신 뒤로 옮겨졌다

여기까지 하면 feature 는 main 보다 D', E' 두 커밋만큼 앞서 있어요. 이제 main 으로 돌아가서 합치면, 갈래가 없으니 병합 커밋도 없이 main 이 그냥 앞으로 쭉 따라가요. 이걸 A-2 에서 배운 fast-forward(빨리 감기) 병합 이라고 했죠.

git switch main
git merge feature
# Updating 3c4d5e6..e5f6a7b
# Fast-forward

결과적으로 main 의 역사가 병합 커밋 하나 없이 완벽하게 한 줄로 정리됐어요. 이게 많은 팀이 "내 기능 브랜치는 합치기 전에 rebase 로 한번 정리한다" 를 선호하는 이유예요. 나중에 git log 를 봤을 때 역사가 직선이라 읽기가 편하거든요.

🌟 GUI 로는 — GitHub Desktop 에서 Branch 메뉴의 Rebase current branch... 를 고르면 같은 작업을 버튼으로 할 수 있어요. 다만 rebase 는 명령어로 익히는 걸 강하게 권해요. 화면마다 메뉴 위치가 다르고, 실무에선 결국 터미널에서 다루게 되거든요.

여기서 A-4 의 한 장면이 떠오르죠. push 가 거부돼 git pull 했을 때, 사실 거기에도 같은 선택이 숨어 있었어요. git pull --rebase 를 쓰면 병합 커밋을 만들지 않고 내 커밋을 원격 최신 뒤로 옮겨 붙여요. 말하자면 pull = fetch + rebase 인 셈이죠. 매번 이렇게 직선으로 받고 싶으면 git config --global pull.rebase true 로 기본값을 정해둘 수 있어요. 직선 역사를 좋아하는 팀이 즐겨 쓰는 설정이에요.

💡 한 줄 정리

feature 브랜치에서 git rebase main 을 하면 내 커밋을 main 최신 뒤로 옮겨 붙여 갈래를 없앤다. 그 뒤 main 으로 와서 git merge feature 하면 병합 커밋 없는 fast-forward 로 역사가 한 줄로 깔끔하게 정리된다.

Step 3: "rebase 도중 멈췄을 때 — 충돌 해결"

rebase 가 늘 매끄럽게 끝나면 좋겠지만, 가끔 도중에 충돌(conflict) 이 나서 멈춰요. A-2 에서 본 그 충돌, merge 할 때 같은 줄을 양쪽이 다르게 고치면 났던 거 기억하시죠? rebase 도 똑같이 충돌이 날 수 있어요. 다만 멈추는 방식이 조금 달라요.

merge 는 충돌을 한 번에 모아서 보여줬어요. 그런데 rebase 는 커밋을 하나씩 차례대로 다시 얹기 때문에, 충돌이 나는 그 커밋에서 멈춰요. D' 를 얹다 충돌나면 거기서 멈추고, 해결하면 다음 E' 를 얹다가 또 충돌날 수도 있어요. 즉 커밋 개수만큼 여러 번 멈출 수 있어요.

충돌이 나면 이런 안내가 떠요.

git rebase main
# CONFLICT (content): Merge conflict in notes.txt
# error: could not apply f6e5d4c... 내 작업 D
# hint: Resolve all conflicts manually, mark them as resolved with
# hint: "git add", then run "git rebase --continue".

해결 방법은 merge 충돌 때와 똑같아요. 충돌난 파일을 열면 <<<<<<< 표시가 있고, 그 안에 양쪽 버전이 들어 있어요. 원하는 내용으로 정리한 뒤 표시를 지우고, git add 로 "해결했다" 고 알린 다음, merge 때와 달리 commit 이 아니라 git rebase --continue 로 다음 커밋을 이어서 얹어요.

# 1. 충돌난 파일을 열어 원하는 내용으로 정리하고 <<<<<<< 표시를 지운다
# 2. 해결했다고 알린다
git add notes.txt
# 3. 멈춘 지점부터 rebase를 이어서 진행한다
git rebase --continue

여기서 가장 중요한 안심 장치를 알려드릴게요. rebase 도중에 "아, 이거 너무 꼬였다. 그냥 없던 일로 하고 싶다" 싶으면, 언제든 git rebase --abort 한 줄로 rebase 시작 전 상태로 완전히 되돌아가요. 충돌이 산더미여도, 뭘 잘못 건드린 것 같아도, abort 하면 깨끗하게 원위치예요. 그러니 rebase 도중 막혀도 절대 당황하지 마세요.

⚠️ rebase 가 무섭게 느껴지는 가장 큰 이유가 바로 이 "도중에 멈춤" 이에요. 그런데 알고 보면 길은 셋뿐이에요 — 해결하고 --continue, 그만두고 --abort, 건너뛰고 --skip. 막히면 일단 --abort 로 원위치하고 처음부터 천천히 다시 해도 전혀 문제없어요.

💡 한 줄 정리

rebase 는 커밋을 하나씩 얹으므로 충돌 시 그 커밋에서 멈추고, 여러 번 멈출 수 있다. 충돌난 파일을 정리하고 git add 한 뒤 git rebase --continue 로 이어간다. 너무 꼬이면 git rebase --abort 한 줄로 시작 전 상태로 완전히 되돌아갈 수 있으니 안심해도 된다.

Step 4: "커밋을 편집하는 화면 — rebase -i 기초"

지금까지는 브랜치 전체를 옮기는 rebase 였어요. 이제 rebase 의 진짜 강력한 쓰임새를 봐요. 바로 인터랙티브 rebase(interactive rebase), 줄여서 rebase -i 예요. 이건 "내 최근 커밋 몇 개를 펼쳐놓고, 합치거나 메시지를 고치거나 지우는" 커밋 편집 도구예요.

언제 필요할까요? 혼자 작업하다 보면 커밋이 이렇게 지저분해지기 쉬워요. "로그인 폼 추가" → "오타 수정" → "ㅇㅇ" 같은 식으로요. A-1 에서 강조한 좋은 커밋 메시지와는 거리가 멀죠. 이런 걸 합쳐서 깔끔한 커밋 하나로 만들 때 rebase -i 를 써요.

먼저 화면을 띄우는 명령이에요. HEAD~3 은 "지금(HEAD)부터 뒤로 3개 커밋" 이라는 뜻이에요. 최근 3개를 편집하겠다는 거죠.

git rebase -i HEAD~3

이걸 실행하면 텍스트 편집기가 열리면서, 최근 3개 커밋이 오래된 것이 위로 쭉 나열돼요. 각 줄 맨 앞의 pick 이 "이 커밋을 어떻게 처리할지" 를 정하는 명령어예요.

   pick f6e5d4c  로그인 폼 추가
   pick a1b2c3d  오타 수정
   pick 9z8y7x6  ㅇㅇ

   # 명령:
   # p, pick   = 이 커밋을 그대로 둔다
   # r, reword = 커밋 내용은 두고 메시지만 고친다
   # e, edit   = 이 커밋에서 잠깐 멈춰 내용을 고친다
   # s, squash = 위 커밋에 합치되, 메시지도 합쳐서 다시 쓴다
   # f, fixup  = 위 커밋에 합치되, 이 커밋 메시지는 버린다
   # d, drop   = 이 커밋을 삭제한다

여기서 할 일은 단순해요. 각 줄의 맨 앞 단어 pick 을 원하는 명령으로 바꿔 쓰고, 저장하고 닫는 것 뿐이에요. 그러면 git 이 그 지시대로 커밋들을 다시 정리해줘요. 여섯 가지 명령을 표로 정리하면 이래요.

이번 Step 에서는 이 화면을 읽는 법과 여섯 명령의 뜻만 익혔어요. 실제로 지저분한 커밋을 합치는 건 다음 Step 에서 직접 해봐요.

💡 한 줄 정리

git rebase -i HEAD~N 은 최근 N 개 커밋을 편집기에 펼쳐놓고, 각 줄 앞의 명령(pick/reword/edit/squash/fixup/drop)을 바꿔 커밋을 합치거나 메시지를 고치거나 지우는 커밋 편집 도구다. 명령을 바꿔 저장하면 git 이 그대로 역사를 다시 정리한다.

Step 5: "지저분한 커밋을 깔끔히 — squash·fixup·reword"

이제 Step 4 에서 익힌 화면으로 실제 정리를 해봐요. 상황은 이래요. 로그인 폼을 만들면서 커밋을 이렇게 쌓았어요.

git log --oneline
# 9z8y7x6 (HEAD -> feature) ㅇㅇ
# a1b2c3d 오타 수정
# f6e5d4c 로그인 폼 추가

"오타 수정" 과 "ㅇㅇ" 는 사실 "로그인 폼 추가" 작업의 일부인데, 따로 커밋되는 바람에 역사가 지저분해졌어요. 6개월 뒤 동료가 이 로그를 보면 "ㅇㅇ 이 대체 뭘 한 커밋이지?" 하고 당황하겠죠. 이 셋을 깔끔한 커밋 하나로 합쳐봅시다.

git rebase -i HEAD~3 으로 화면을 열고, 맨 위의 "로그인 폼 추가" 는 pick 으로 살리고, 나머지 둘은 그 위로 흡수시키게 fixup 으로 바꿔요. 자잘한 수정 커밋이라 메시지는 버려도 되니까 squash 가 아니라 fixup 이에요.

   pick   f6e5d4c  로그인 폼 추가
   fixup  a1b2c3d  오타 수정      ← 위로 흡수, 메시지 버림
   fixup  9z8y7x6  ㅇㅇ           ← 위로 흡수, 메시지 버림

이대로 저장하고 닫으면, git 이 세 커밋을 하나로 합쳐요. 로그를 다시 보면 깔끔하죠.

git log --oneline
# e5f6a7b (HEAD -> feature) 로그인 폼 추가

만약 합치면서 메시지도 더 좋게 다듬고 싶다면, 합친 뒤 그 커밋을 reword 로 한 번 더 손보거나, 처음부터 fixup 대신 squash 를 써서 메시지를 합치는 화면을 띄울 수 있어요. 정리하면 이런 그림이에요.

   Before — 지저분한 세 커밋          After — 의미 있는 한 커밋

   ● ㅇㅇ                            ● 로그인 폼 추가
   ● 오타 수정             ──▶            (셋이 하나로 합쳐짐)
   ● 로그인 폼 추가

A-3 에서 배운 git commit --amend 기억나세요? 그건 바로 직전 커밋 하나만 고치는 도구였어요. rebase -i 는 그걸 여러 커밋으로 확장한 거라고 보면 돼요. amend 는 마지막 한 개, rebase -i 는 최근 여러 개. 이렇게 짝지어 기억하면 헷갈리지 않아요.

⚠️ 이렇게 커밋을 합치면 당연히 해시가 새로 바뀌어요(Step 1 에서 본 그 D→D' 예요). 그러니 아직 내 손 안에 있는, 남과 공유하지 않은 커밋에만 쓰세요. 이미 push 해서 동료와 나눈 커밋을 이렇게 합치면 사고가 나요. 이 경계가 바로 Step 7 의 황금률이에요.

한 걸음 더 나가볼게요. 지금까지는 이미 만들어진 커밋을 rebase -i 로 사후에 정리했어요. 그런데 애초에 커밋을 만들 때부터 깔끔하게 나누는 길도 있어요. git add -p 예요. 한 파일 안에서 여러 군데를 고쳤을 때, git add 파일이름 은 그 파일의 변경을 통째로 담지만, git add -p 는 고친 덩어리(hunk)를 하나씩 보여주며 "이건 담을까요?" 하고 물어봐요. y(담기)·n(건너뛰기)로 답하면, 같은 파일이라도 "로그인 버그 수정" 만 따로 골라 한 커밋으로 만들 수 있죠. 사후 정리가 rebase -i 라면, 사전 정리는 git add -p 예요.

💡 한 줄 정리

rebase -i 에서 흡수시킬 커밋을 fixup(메시지 버림) 또는 squash(메시지 합침)로 바꾸면 여러 커밋이 의미 있는 하나로 합쳐진다. 직전 한 커밋만 고치는 amend 의 여러 커밋 버전이라고 보면 된다. 합치면 해시가 바뀌므로 아직 공유 안 한 커밋에만 쓴다.

Step 6: "그 커밋 하나만 가져올게 — cherry-pick"

지금까지는 브랜치 전체나 최근 커밋 묶음을 다뤘어요. 그런데 가끔은 다른 브랜치에 있는 딱 그 커밋 하나만 내 브랜치로 가져오고 싶을 때가 있어요. 브랜치 전체를 합치는 게 아니라, 체리를 콕 집어 따듯 커밋 하나만 골라오는 거예요. 그래서 이름도 cherry-pick(체리 피크) 이에요.

상황을 그려볼게요. 동료가 feature-A 브랜치에서 작업하다가, 거기서 급한 버그 하나를 고친 커밋을 만들었어요. 그런데 그 버그 수정은 지금 당장 main 에도 필요해요. feature-A 전체는 아직 안 끝나서 통째로 합칠 순 없고, 그 버그 수정 커밋 하나만 main 으로 가져오고 싶어요. 이때 cherry-pick 이에요.

쓰는 법은 간단해요. 가져갈 곳(main)으로 가서, 가져올 커밋의 해시를 적어주면 돼요.

git switch main
git cherry-pick a1b2c3d
# [main 7f8e9d0] 급한 버그 수정
#  Date: ...
#  1 file changed, 2 insertions(+), 1 deletion(-)

그러면 a1b2c3d 커밋이 담고 있던 변경이 main 위에 새 커밋으로 복사돼서 얹혀요. 그림으로 보면 이래요.

   feature-A  ●───●───◆───●        ◆ = 급한 버그 수정 커밋
                                    
   cherry-pick 후:
   main       ●───●───◆'           └ ◆ 하나만 main으로 복사됨(◆')

여기서도 가져온 커밋의 해시가 바뀌는 거 보이세요(다이어그램의 프라임 표시)? cherry-pick 도 커밋을 새로 복사해 만드는 거라 해시가 바뀌어요. rebase 와 같은 원리예요.

cherry-pick 도 가져오는 변경이 현재 브랜치와 겹치면 충돌이 날 수 있어요. 그때도 rebase 와 똑같이 길이 셋이에요 — 충돌을 해결하고 git cherry-pick --continue, 그만두고 git cherry-pick --abort.

⚠️ cherry-pick 은 편리하지만 남용하면 안 돼요. 같은 변경을 이 브랜치 저 브랜치에 자꾸 복사하면, 똑같은 내용이 해시만 다른 커밋으로 여기저기 흩어져서 나중에 역사가 헷갈려져요. "정말 이 커밋 하나만 급히 필요할 때" 의 도구로 아껴 쓰고, 평소엔 merge 나 rebase 로 브랜치를 통째로 합치는 게 정석이에요.

🌟 GUI 로는 — cherry-pick 은 VS Code 의 GitLens 확장에서 커밋을 우클릭해 고를 수 있어요. GitHub Desktop 은 cherry-pick 을 직접 지원하지 않아서, 이 작업은 명령어가 가장 확실해요.

💡 한 줄 정리

git cherry-pick <해시> 는 다른 브랜치의 특정 커밋 하나만 골라 현재 브랜치 위에 새 커밋으로 복사해 얹는다(해시는 바뀐다). 급한 버그 수정 한 건을 다른 브랜치에도 적용할 때처럼, 브랜치 전체가 아니라 커밋 하나만 필요할 때 아껴 쓴다.

Step 7: "절대 건드리면 안 되는 선 — rebase 황금률"

오늘 내내 "rebase 는 역사를 고쳐 쓴다, 커밋 해시가 바뀐다" 를 반복해서 짚었죠? 이제 그 모든 경고가 모이는 단 하나의 황금률을 박을 시간이에요. 지난 시간 마지막에 예고했던 그 약속이에요.

이미 남과 공유한(push 한) 브랜치는, 절대 rebase 하지 않는다.

왜 이게 그렇게 중요할까요? 그림으로 보면 단숨에 이해돼요. 내가 main 의 커밋 D 를 동료와 공유한 상태에서, 나 혼자 rebase 로 D 를 D' 로 고쳐 썼다고 해봐요.

   동료의 컴퓨터:  A───B───C───D      ← 동료는 아직 옛 D를 갖고 있다
   내 컴퓨터:      A───B───C───D'     ← 나는 rebase로 D를 D'로 바꿈

   → 같은 작업인데 커밋이 D와 D'로 갈라졌다.
     이제 둘을 합치면 역사가 꼬이고 충돌이 폭발한다.

보세요. 동료는 여전히 옛날 커밋 D 를 기준으로 작업하고 있는데, 나는 D 를 없애고 D' 를 만들어버렸어요. 이제 동료가 자기 작업을 push 하거나 내 변경을 받아오면, git 은 "D 가 맞아, D' 가 맞아?" 하고 혼란에 빠져요. 같은 내용인데 다른 커밋이 둘이 돼버렸으니까요. 결국 동료의 저장소와 내 저장소가 엉켜서, 풀어내느라 한참 고생하게 돼요. 현업 신입이 "내가 rebase 한 번 잘못했더니 팀 전체가 멈췄어요" 하고 식은땀 흘리는 사고가 바로 이거예요.

그래서 선을 이렇게 그어요.

핵심은 "남이 그 커밋 위에서 작업하고 있느냐" 예요. 아무도 안 건드리는 내 작업이면 얼마든지 깔끔하게 정리해도 되고, 남이 딛고 선 커밋이면 절대 발밑을 바꾸면 안 돼요.

그런데 현업에서 "이 PR 브랜치 main 위로 rebase 해주세요" 라는 말은 정말 자주 들어요. 이건 황금률 위반이 아니에요. 보통 그 PR 브랜치는 나 혼자 쓰는 브랜치라, 최신 main 위로 rebase 해서 역사를 깔끔히 맞춰달라는 뜻이거든요. 겁먹을 필요 없어요. "내 브랜치는 OK, 공유 브랜치는 금지" 만 기억하면 돼요.

💡 한 줄 정리

rebase 의 황금률은 "남과 공유한(남이 그 위에서 작업하는) 브랜치는 절대 rebase 하지 않는다" 이다. rebase 는 커밋을 새로 만들어 역사를 갈라놓기 때문이다. 아직 나만 가진 로컬 브랜치나 혼자 쓰는 PR 브랜치는 마음껏 정리해도 되고, main 같은 공용 브랜치는 손대지 않는다.

Step 8: "부득이할 땐 안전하게 — push --force-with-lease"

Step 7 의 끝에서 숙제가 하나 생겼죠. 내 PR 브랜치를 rebase 로 정리하면, 커밋 해시가 바뀌어서 이미 GitHub 에 올라간 원격과 역사가 달라져요. 이 상태로 평범하게 git push 를 하면 git 이 거부해요.

git push
# ! [rejected]        feature -> feature (non-fast-forward)
# error: failed to push some refs to '...'
# hint: Updates were rejected because the tip of your current branch is behind

git 이 "어? 원격이랑 역사가 안 맞는데? 그냥 밀어 넣으면 위험해" 하고 막아주는 거예요. 이건 고마운 보호 장치예요. 이럴 때 "내가 일부러 역사를 고쳐 쓴 게 맞으니 밀어 넣겠다" 고 알려주는 게 강제 push 예요. 그런데 강제 push 에도 위험한 길과 안전한 길이 있어요.

위험한 길은 그냥 git push --force 예요. 이건 원격에 뭐가 있든 무조건 내 걸로 덮어써요. 만약 내가 모르는 사이 동료가 그 브랜치에 뭔가 올렸다면, 그 동료의 커밋이 소리 소문 없이 사라져요. 이게 "잘못된 force-push 로 동료 작업 날렸다" 는 그 무서운 사고예요.

안전한 길은 git push --force-with-lease 예요. 이름이 좀 어렵지만 뜻은 단순해요. "내가 마지막으로 본 원격 상태가 그대로일 때만 덮어쓴다" 는 조건을 거는 거예요. 즉 내가 모르는 새 변경이 원격에 있으면 push 를 거부하고 멈춰줘요. 동료가 뭔가 올렸다면 덮어쓰기 전에 알려주는 거죠.

git push --force-with-lease
# 원격이 내가 본 그대로면 → 안전하게 덮어쓰기 성공
# 그 사이 동료가 뭔가 올렸다면 → 거부하고 멈춤 (동료 작업 보호)

🌟 한 끗 더 안전하게 — --force-with-lease 에 --force-if-includes 를 함께 쓰면(git push --force-with-lease --force-if-includes), 내가 원격 변경을 실제로 받아봤는지까지 확인해서 더 안전해요. 매번 치기 번거로우면 git config --global push.useForceIfIncludes true 를 한 번 켜두면 --force-with-lease 만 써도 이 보호가 자동으로 따라와요. 실무에선 이 설정을 켜두는 걸 권해요.

마지막으로 가장 든든한 안심 장치를 다시 꺼낼게요. 혹시 강제 push 든 rebase 든 뭔가 정말 잘못 만졌어도, A-3 에서 배운 git reflog 가 있어요. reflog 는 "내가 거쳐온 모든 상태" 를 기록해둔 구조대라, 망친 직전 상태의 해시를 찾아 git reset 으로 돌아갈 수 있어요. 그러니 오늘 배운 도구들, 무서워하지 말고 연습 저장소에서 마음껏 시험해보세요. 길을 잃어도 돌아올 지도가 있으니까요.

🌟 GUI 로는 — GitHub Desktop·VS Code 의 'Force push' 버튼은 대개 위험한 --force 와 같게 동작해요. 그래서 GUI 로 강제 push 할 땐 더 조심하고, 가능하면 명령어로 --force-with-lease 를 쓰는 게 안전해요.

💡 한 줄 정리

rebase 로 정리한 브랜치를 push 하면 역사가 달라 거부되는데, 이때 git push --force 는 동료 커밋을 날릴 수 있어 위험하다. git push --force-with-lease 는 내가 본 원격 상태가 그대로일 때만 덮어써서, 모르는 변경이 있으면 멈춰 동료 작업을 지킨다. 그래도 망치면 reflog 로 되돌릴 수 있다.

마무리

오늘 우리는 git 의 가장 강력하면서도 조심스러운 도구, 역사를 다시 쓰는 법을 익혔어요. merge 와 rebase 가 역사를 어떻게 다르게 만드는지 그림으로 구분했고, rebase 로 가지를 옮기고 충돌을 빠져나오는 법을 익혔죠. rebase -i 로 지저분한 커밋을 깔끔한 하나로 합치고, cherry-pick 으로 필요한 커밋만 골라오는 법도 배웠어요. 그리고 무엇보다, 이 모든 힘을 안전하게 쓰는 황금률과 --force-with-lease, 그리고 망쳐도 돌아올 reflog 라는 지도까지 챙겼어요. 처음엔 무섭던 단어들이 이제 조금은 익숙해졌길 바라요.

오늘 배운 핵심 세 가지

• 💡 하나 — merge 는 사실 그대로, rebase 는 깔끔하게. merge 는 병합 커밋을 남겨 갈래를 보존하고, rebase 는 커밋을 옮겨 붙여 역사를 한 줄로 편다. 단 rebase 는 커밋을 새로 만들어(해시가 바뀐다) 역사를 고쳐 쓴다.
• 💡 둘 — 커밋은 합치고 고르고 다듬을 수 있다. rebase -i 의 squash·fixup·reword 로 지저분한 커밋을 의미 있는 하나로 정리하고, cherry-pick 으로 특정 커밋만 골라 가져온다.
• 💡 셋 — 역사를 고쳐 쓸 땐 황금률과 안전한 push. 남과 공유한 브랜치는 절대 rebase 하지 않는다. 부득이 강제 push 가 필요하면 --force 가 아니라 --force-with-lease 로, 그래도 망치면 reflog 로 되돌린다.

다음 시간 예고

오늘로 협업 git 의 고급 도구는 거의 다 챙겼어요. 다음 시간(A-8)은 이 과목의 마지막 모듈이자, 지금까지 배운 모든 걸 실전에서 묶는 시간이에요.

오늘 rebase 도중에 커밋이 하나씩 얹히는 걸 봤죠? 그 과정에서 가끔 HEAD 가 어느 브랜치에도 붙어 있지 않은 이상한 상태(detached HEAD) 에 빠질 수 있어요. 다음 시간엔 그게 뭔지, 어떻게 빠져나오는지를 다뤄요. 그리고 오늘 경고한 "잘못된 force-push 로 동료 커밋이 사라진" 사고를 reflog 로 실제로 복구하는 법, 흔한 협업 사고에서 빠져나오는 트러블슈팅도 함께 봐요.

마지막으로 살짝 설레는 예고 하나. PR 을 올리면 자동으로 코드를 검사해서 초록색 체크 표시가 뜨는 걸 본 적 있을 거예요. 그게 어떻게 동작하는지, GitHub Actions 로 아주 간단한 자동 검사 하나를 직접 만들어 체감해봐요. 본격적인 자동화는 인프라 과목의 몫이지만, "아, 이런 거구나" 하는 첫 감은 다음 시간에 잡아요. 이 과목의 피날레, 기대해주세요.

과제

오늘 배운 건 눈으로만 보면 절대 안 익어요. 특히 rebase 는 직접 망쳐보고 --abort 로 되돌려봐야 무섭지 않다는 걸 몸으로 알게 돼요. 꼭 여러분 연습 저장소에서 직접 쳐보세요. 안심하고요 — 연습 저장소는 망쳐도 아무 일도 안 일어나요.

[기초] 지저분한 커밋 세 개를 하나로 합치기

연습 저장소에서 일부러 지저분한 커밋을 쌓은 뒤 rebase -i 로 정리해보세요.

작은 파일 하나를 만들고, "메모 작성" → "오타 고침" → "ㅇㅇ" 처럼 세 번에 나눠 커밋하세요(메시지를 일부러 대충 지어보세요). 그다음 git rebase -i HEAD~3 으로 화면을 열어, 맨 위는 pick, 나머지 둘은 fixup 으로 바꿔 저장하세요. 마지막으로 git log --oneline 으로 커밋이 의미 있는 하나로 합쳐졌는지 확인하고, "왜 squash 가 아니라 fixup 을 골랐는지" 를 한 문장으로 적어보세요.

[응용] feature 브랜치를 main 최신 위로 rebase 하기

main 이 앞서간 상황을 직접 만들어, 내 기능 브랜치를 그 위로 rebase 해보세요.

main 에서 feature 브랜치를 따 커밋을 하나 만든 뒤, main 으로 돌아가 다른 파일에 커밋을 하나 더 올려 main 을 앞서가게 하세요(갈래가 생겨요). 그다음 git switch feature → git rebase main 으로 내 작업을 main 최신 뒤로 옮기고, git log --oneline --graph --all 로 갈래가 한 줄로 펴졌는지 확인하세요. 마지막으로 "rebase 전과 후의 그래프 모양이 어떻게 달라졌는지" 를 한두 문장으로 적어보세요.

상상해보세요 — 입사 후 내 PR 브랜치를 며칠 두는 사이 동료들이 main 에 여러 변경을 올린 상황이요. 그때 "PR 을 최신 main 위로 rebase 해서 올려주세요" 라는 요청을 받게 될 거예요. 오늘 이 연습이 그대로 그 상황이에요.

[심화] 황금률을 말로 설명하고, 안전한 강제 push 짚기

명령을 외우는 걸 넘어, 왜 그렇게 하는지를 스스로 설명해보는 과제예요.

먼저 응용 과제에서 rebase 한 feature 브랜치가 이미 GitHub 에 올라가 있었다고 가정하고, 왜 평범한 git push 가 거부되는지, 그때 git push --force 대신 git push --force-with-lease 를 써야 하는 이유가 무엇인지 두세 문장으로 적어보세요. 그다음 "그렇다면 main 브랜치는 왜 절대 rebase 하면 안 되는지" 를 황금률의 관점에서 설명해보세요. (여유가 되면 연습 저장소의 내 브랜치에서 --force-with-lease 를 실제로 한번 써봐도 좋아요. 어차피 나 혼자 쓰는 브랜치라 안전해요.)

생각해볼 주제

1. 우리 팀의 커밋 역사, 직선이 좋을까 갈래가 좋을까

어떤 팀은 "역사는 무조건 한 줄로 깔끔해야 읽기 좋다" 며 합치기 전에 늘 rebase 를 하고, 어떤 팀은 "있었던 일은 그대로 보여야 한다" 며 merge 의 병합 커밋을 일부러 남겨요. 둘 다 일리가 있어요. 여러분이 팀의 리드라면 어느 쪽을 택하겠어요? 6개월 뒤 버그를 추적하려고 git log 를 뒤지는 상황을 떠올리면, 직선 역사의 가독성과 갈래 역사의 사실성 중 무엇이 더 도움이 될지 견줘보세요.

2. 황금률을 어겼을 때, 실제로 동료에게 무슨 일이 생길까

내가 main 을 rebase 해서 push 해버렸다고 해봐요. 다음 날 출근한 동료가 평소처럼 git pull 을 하면 무슨 일이 벌어질까요? 동료의 화면엔 어떤 메시지가 뜨고, 동료의 로컬 작업은 어떻게 될까요? "커밋 해시가 바뀐다" 는 오늘의 핵심을, 동료의 입장에서 한 번 따라가 보세요. 왜 이 규칙이 '권장' 이 아니라 '황금률' 이라는 강한 이름을 가졌는지 몸으로 와닿을 거예요.

3. 커밋을 squash 로 합치면, 우리가 잃는 것은 없을까

rebase -i 로 커밋 다섯 개를 깔끔한 하나로 합치면 역사가 읽기 좋아져요. 그런데 합치는 순간, 그 다섯 단계로 나뉘어 있던 "작업의 과정" 은 사라져요. 어떤 순서로 고민하며 만들어갔는지가 한 커밋 안에 뭉개지는 거죠. 깔끔한 역사를 위해 작업 과정의 기록을 버리는 게 늘 이득일까요? "언제는 합치는 게 낫고, 언제는 단계를 남겨두는 게 나은지" 를 여러분 나름의 기준으로 정리해보세요.