IT 시행착오··약 5분

노트북 세 대에서 git이 꼬일 때…stale main에서 딴 브랜치가 PR에 과거 코드를 끌고 오는 이유

컴퓨터를 바꿀 때 pull을 건너뛰고 브랜치를 따면 PR에 예전 커밋이 섞인다. 다중 기기 워크플로에서 실제로 막힌 지점과 rebase·wip 브랜치 대응을 정리한다.

git 브랜치 워크플로 다이어그램 — 다중 기기에서 main 동기화 맥락 (cc by-sa 4.0, wikimedia-commons)

블로그 레포를 노트북·데스크톱·클라우드 에이전트 VM에서 번갈아 열다 보면, 가끔 “분명 고친 코드가 PR에는 없고 예전 파일이 돌아온다” 는 상황이 난다. 원인은 대부분 복잡한 merge conflict가 아니라, B 기기의 main이 A 기기에서 이미 머지된 최신 상태를 따라가지 못한 채 브랜치를 딴 것이다. 노션에 정리해 둔 다중 기기 git 메모를 바탕으로, 실제로 막혔던 패턴과 대응만 추려 적는다.

사실: 증상은 이렇게 보인다

전형적인 흐름은 다음과 같다. A 노트북에서 feature/blog-automation 브랜치로 글쓰기 규칙을 수정하고 main에 머지했다. 다음 날 B 데스크톱에서 git checkout main만 하고 pull을 잊은 채 feature/hero-image-fix를 만든다. B에서 고친 건 frontmatter 한 줄인데, PR diff에는 이미 A에서 삭제한 옛 스크립트가 다시 살아 있거나, 카테고리 상수와 충돌하는 예전 consts.ts 조각이 끼어 들어온다.

에이전트 워크트리 환경에서는 한 단계 더 헷갈린다. 격리된 worktree의 main이 원격과 어긋나 있으면, 에이전트가 “최신 main에서 브랜치를 땄다”고 로그에 남겨도 실제 base commit이 하루 전일 수 있다. 사람이 눈으로 git log --oneline -3을 안 보면 PR 단계에서야 발견한다.

이유: pull 없이 브랜치를 따면 base가 과거에 고정된다

git은 브랜치를 만들 때 현재 HEAD가 가리키는 커밋을 출발점으로 삼는다. main이 원격보다 10커밋 뒤처져 있으면, 새 feature/*도 그 10커밋 이전 세계에서 출발한다. 이후 git push와 PR 생성은 정상적으로 보이지만, GitHub가 비교하는 base는 “옛 main → 새 브랜치”이므로 이미 main에 합쳐진 변경을 되돌리는 diff가 PR에 섞일 수 있다.

노션 메모의 “규칙 1: 컴퓨터를 바꾸면 무조건 git pull origin main”은 과장이 아니다. fetch만 하고 merge/rebase를 안 하면 로컬 main은 여전히 옛 상태다. git status가 clean이어도 원격 대비 behind일 수 있으므로, 작업 시작 루틴에 git fetch origin && git status -sb를 넣는 편이 낫다.

rebase를 쓰는 팀이라면 PR 전에 git rebase main으로 브랜치 바닥을 최신화해야 한다. 이미 push한 브랜치면 --force-with-lease가 필요하다. 메모에 적힌 대로, force push는 브랜치를 혼자 쓸 때만 하고, 공유 브랜치에서는 merge commit을 받아들이는 쪽이 안전하다.

평가: 습관 하나와 임시 브랜치 하나면 대부분 끝난다

실무에서 효과가 큰 조합은 두 가지다.

첫째, 기기 전환 시 고정 문장: checkout main → pull → 새 브랜치. main에서 직접 커밋하지 않는다. 블로그 자동화처럼 cron이 main에 바로 push하는 예외가 있어도, 사람이 손대는 수정은 브랜치로 분리하면 롤백이 쉽다.

둘째, 미완성 작업은 wip/ 브랜치로 push. 퇴근 전 PR까지 못 올리면 wip/2026-08-10-hero처럼 올려 두고 다음 기기에서 git fetch && git checkout wip/...로 이어간다. 노션 메모의 “PR 전 rebase”는 wip를 main에 합치기 직전에 한 번 돌리면 된다.

feature 브랜치를 머지 후 재사용하지 말라는 메모도 맞다. 같은 이름으로 두 번째 작업을 시작하면 PR diff에 지난번 머지 커밋까지 섞여 리뷰가 불가능해진다. 브랜치 삭제 비용은 거의 없다.

부연: 어디에 안 쓰는지

혼자 쓰는 사이드 프로젝트에서 한 기기·한 브랜치만 쓴다면 이 글의 절차는 과하다. 반대로 에이전트 + 로컬 + 노트북이 같은 repo를 건드리면 pull 생략 한 번이 배포 롤백으로 이어질 수 있다.

git pull --rebase와 merge 중 팀 규칙이 정해져 있지 않다면, 블로그 정적 레포처럼 충돌이 드문 곳은 pull 시 rebase를 써도 된다. 다만 이미 열린 PR 브랜치를 rebase한 뒤 force push할 때는 CI가 다시 도는지 확인한다.

API 토큰·내부 호스트명·고객사 실명은 글에 넣지 않았다. 노션 시드에 있던 배포 토큰 예시는 전부 마스킹·삭제했다.

출처

  • Notion 시드: «깃을 밀어내고 작업» — 다중 기기 pull·wip 브랜치·rebase 절차 (공개 가능 요지만)
  • 내부 실측: 블로그 레포에서 git fetch origin && git status -sb로 behind 커밋 수 확인, worktree 격리 환경에서 base commit 시각 대조