주짓수로 Git 피로 극복

Source: Hacker News

이 글은 jujutsu 버전 관리 시스템에 대한 기본적인 이해를 전제로 합니다. jujutsu를 사용해 본 적이 없더라도 아이디어의 핵심은 파악할 수 있지만, 이후에 Steve의 Jujutsu 튜토리얼을 읽어보는 것을 권장합니다.

대규모 기능을 개발할 때, 좋은 커밋(Good Commits) 을 작성하는 것은 어렵습니다.

그리고 여기서 말하는 좋은 커밋은 다음과 같은 형태를 의미합니다.
define types
add DB functions
server CRUD
client API
client UI

이렇게 하면 리뷰어가 풀 리퀘스트를 작은 단위로 단계별로 살펴볼 수 있고, 각 변경 세트가 기능의 한 측면에만 국한됩니다.

그래서 저는 자연스럽게 다음과 같이 커밋합니다.
define types
add DB functions
WIP test code
server CRUD
client API and UI
fix DB function
fix UI bug
refactor CRUD
fix another UI bug

후자의 커밋들은 앞서 만든 작업을 덮어쓰게 되고, 스토리가 깨집니다.

⚖️ Jujutsu 는 커밋 사이를 자유롭게 오가며 분리된 변경 세트를 빠르게 반복할 수 있게 해 주지만, 여전히 어느 정도 노력이 필요하고 나는 종종 꺼리게 됩니다.

🤖 [jj absorb](https://docs.jj-vcs.dev/latest/cli-reference/#jj-absorb) 은 어느 정도 도움이 되며, [jj squash -i](https://docs.jj-vcs.dev/latest/cli-reference/#jj-squash) 도 마찬가지지만 두 도구 모두 단점이 있습니다.

• absorb 는 파일을 가장 최근에 건드린 이전 커밋을 기준으로 변경을 할당하는데, 이는 때때로 실제로 해당 변경을 소유해야 하는 커밋과 일치하지 않을 수 있습니다.
• squash -i 는 경계가 아주 깔끔하지 않으면 병합 충돌 지옥에 빠질 수 있습니다.

그래서 제가 만든 “git 엄격함 피로(git rigour fatigue)” 를 해소하는 방법을 소개합니다. 예시를 위해 커밋을 시각적으로 표현해 보겠습니다. 빨간색은 타입 정의 변경, 파란색은 UI 변경 등을 의미합니다.

혼란: 첫 번째 커밋은 빨간색과 파란색이 섞여 있습니다. 빨간색을 여러 곳에서 건드리고 있죠!

이를 해결하기 위해 먼저 이상적인 커밋 히스토리를 만들겠습니다.

jj new -B messy-first -m 'red'

그 다음에 나머지 작업을 진행합니다. (이 시점에서 jj new -A red -m 'blue' 로 전환)

실제 변경이 있는 모든 커밋을 하나로 합칩니다.

jj squash --from messy-first..messy-last --into messy-first

그 후에

jj squash -i --from messy-first --into red

를 사용해 빨간색 변경만 골라 red 박스로 옮깁니다.

이 과정을 반복하면 결국 모든 변경이 올바른 위치에 들어가고, “everything commit” 은 비어 있게 됩니다.

대규모 기능을 개발할 때, 저는 이 워크플로우가 기능 개발 전반에 걸쳐 엄격한 git 규칙을 유지하는 것보다 훨씬 쉽다고 느낍니다. 임시 디버깅 상태가 포함된 즉흥적인 커밋을 만든 뒤, 마지막에 한 번에 깔끔하게 정리할 수 있기 때문입니다.

preemptions:

이 기법에 딱 맞는 이름이 아직 없습니다. “큰 빨래 더미처럼 커밋하기” 정도가 될까요?

이 방법은 (그리고 개인적으로는) jj split 보다 다르고, 더 우수합니다.

split 을 사용할 경우, 빨간색에 들어가야 할 덩어리(hunk) 를 놓치면 다시 split 하고 squash 해야 합니다.

이 기법은 가장 쉬운 덩어리들을 처음에 정렬하고, 커밋 순서에 미치는 영향을 고민할 필요 없이 작업을 진행할 수 있게 해 줍니다.

마지막에 한 번에 정리하는 것이 (종종) jj squash -i 를 진행 중에 사용하는 것보다 나은 이유는 everything commit 의 최종 상태가 충돌이 없다는 것이 보장되기 때문입니다. “fix red and green” 같은 새로운 커밋을 만들고 이를 인터랙티브하게 red·green 커밋에 스쿼시하면, 해당 파일을 건드리는 blue 커밋이 깨질 수 있습니다.

이 기법의 단점은 모든 커밋이 컴파일된다는 보장이 없다는 점이며, 이는 경우에 따라 큰 장애물이 될 수 있습니다.