아프니까 개발자다 아프니까 개발자다

rebase를 처음 써 본 지인이 물었다. "merge로 합칠 땐 충돌(conflict)이 한 번 났는데, 같은 브랜치를 rebase로 해 봤더니 충돌 해결을 세 번이나 시켰어. 뭔가 잘못한 거야?" 잘못한 게 아니다. 구조적으로 그렇게 설계돼 있다. merge와 rebase는 "브랜치를 합친다"는 결과가 비슷해 보여도 변경을 적용하는 단위가 달라서, 충돌을 만나는 횟수와 방식이 다르다. 이 차이를 모르면 rebase 도중 반복되는 충돌 앞에서 "git이 고장났나?" 하는 공포에 빠지기 쉽다.충돌이란 무엇인가 — 기계가 판단을 포기하는 지점먼저 충돌 자체를 정확히 하자. git은 두 변경을 합칠 때 대부분 자동으로 처리한다 — 서로 다른 파일, 또는 같은 파일의 서로 다른 영역을 고쳤다면 둘 다 반영하면..

git을 배우는 지인에게 rebase를 소개했더니 바로 이런 반응이 돌아왔다. "찾아보니까 다들 위험하다던데? 히스토리가 날아간다며?" 커뮤니티에는 실제로 "공개된 브랜치에서는 절대 rebase 하지 마라"가 격언처럼 돌고, Pro Git 책에도 "Do not rebase commits that exist outside your repository and that people may have based work on"이라고 박혀 있다. 그런데 "위험하다"만 듣고 이유를 모르면 두 가지 잘못된 극단으로 간다 — rebase를 아예 안 쓰거나(깔끔한 히스토리 도구를 버림), 규칙의 경계를 모른 채 쓰다가 사고를 낸다.이 글은 그 격언의 근거 하나를 파고든다. rebase는 커밋을 옮기는 게 아니라 복제한 뒤..

git을 처음 배우는 지인이 물었다. "GitHub에서 PR(Pull Request, 브랜치를 합쳐 달라고 요청하는 기능) 머지 버튼을 누르려는데 옵션이 세 개나 있어. Merge commit, Squash and merge, Rebase and merge. 뭘 눌러야 해?" 나도 처음엔 아무거나 눌렀다. 셋 다 "브랜치가 합쳐진다"는 결과는 같아 보이기 때문이다. 그런데 이 세 버튼은 합쳐진 뒤 커밋 히스토리의 모양이 완전히 다르다. 그리고 그 모양의 차이가 몇 달 뒤 "이 버그가 언제 들어왔지?"를 추적할 때 체감 난이도를 가른다.이 글은 세 방식이 커밋 그래프에서 실제로 무슨 일을 하는지를 그림으로 비교한다. 결론부터 말하면 셋의 차이는 단 하나의 질문으로 요약된다 — "작업 과정의 역사를 보존할 ..