도구가 “됐다”고 말하고는 아무 일도 하지 않는 경우가 있어요. 에러도 안 나고, 종료 코드도 0이고, 로그도 깨끗한데 결과만 없는 경우요.

그런 일을 며칠 사이에 세 번 겪었고, 세 편으로 나눠 적어보려고 합니다.

셋 다 git과 자동화 이야기예요. 그리고 셋 다 결론이 같습니다. “돌렸다”는 확인이 아니라는 것.

첫 편은 겹침 판정이 틀렸던 이야기입니다.

여러 저장소를 한 일지로 모으고 있었어요

여러 제품을 하나의 기록 금고에 남깁니다. 날짜별 일지에 그날의 커밋 목록이 들어가고, 그건 도구가 채워요.

도구는 저장소를 여러 개 훑습니다. 루트 하나, 그리고 제 저장소로 떠난 제품들이요. 훑어서 모으고, 겹치는 것을 거릅니다.

겹침을 해시로 걸렀어요. 그리고 같은 일이 두 번 적혔습니다.

제품이 떠나도 문장은 남습니다

제품이 처음에는 루트 저장소 안에 살아요. 커지면 제 저장소로 떠나고요. git subtree로 떼어 내든 그냥 복사하든 결과는 같습니다.

그 커밋 문장은 루트 이력에도 그대로 남아요.

루트 저장소     …  "물타기 계산기 키패드 서랍을 다시 짠다"  ← 3f2a1b9
제품 저장소     …  "물타기 계산기 키패드 서랍을 다시 짠다"  ← c84d0e7

사람이 보면 하나의 일이죠. 그런데 도구가 보면 서로 다른 커밋 둘입니다.

해시로 걸러도 안 걸리는 이유는 단순합니다.

커밋 해시는 이런 것들의 지문이에요.

옮겨 심은 커밋은 부모가 달라집니다. 그러니 트리가 완전히 같아도 지문이 달라요. cherry-pick이나 rebase도 마찬가지입니다.

“같은 커밋인가”를 해시로 묻는 것은 같은 저장소 안에서만 통하는 질문이었어요.

그럼 사람은 뭘 보고 같은 일이라고 알까요?

해시가 아니에요. 그날 그 문장입니다.

그래서 도구의 열쇠를 바꿨어요.

날짜 + 제목

이걸 열쇠로 겹침을 거릅니다. 저장소가 달라도 같은 날 같은 문장이면 하나로 봐요.

이 열쇠에는 조건이 붙습니다. 커밋 문장이 “무엇을 했는가”로 또렷해야 해요.

✗  fix
✗  update
✗  wip

○  키패드 서랍이 나가는 곡선으로 떠나게 한다
○  aapt 가 접는 줄바꿈을 검사가 잡게 한다

fix 한 단어짜리 문장은 서로 다른 일까지 하나로 묶어버립니다. 같은 날 fix를 두 번 쓰면 도구는 그중 하나를 지워요.

커밋 메시지를 잘 쓰라는 말은 보통 “나중에 읽을 사람을 위해”인데, 여기서는 이유가 하나 더 생겼습니다. 도구가 읽거든요.

이 도구에 대해 나중에 하나 더 배웠어요.

이력이 다시 쓰이면(스쿼시·리베이스) 옛 커밋은 어느 저장소에도 없게 됩니다. 그때 도구가 “없으니까” 하고 이미 적힌 줄을 걷어내면, 그날 무엇을 했는지가 세상에서 사라져요.

실제로 한 번 그랬습니다. 루트를 두 커밋으로 다시 쓰자 옛 시절 156줄이 일지에서 지워졌어요.

그래서 지금 도구는 표식 안의 옛 줄과 새로 찾은 줄을 합집합으로 씁니다. 새로 못 찾았다는 것이 “그 일이 없었다”는 뜻은 아니니까요.

이번 건 도구가 잘못 판정한 경우였어요. 그래도 결과물은 남았죠.

다음 글은 조금 더 고약합니다. 도구가 아무것도 안 올려놓고 그 사실을 말해주지 않은 이야기예요.