Maiao, 일반 Git 커밋을 1커밋 1PR 스택으로 바꾸는 Gerrit식 리뷰 도구

GitHub의 새 스택 PR 기능을 쓰는지 궁금했음. README가 2024년 GitHub 글을 가리키더라.

내가 유지보수자인데, GitHub가 스택 PR 베타 기능을 내기 전부터 지원했음. 지금은 네이티브 스택에 PR을 추가하는 식으로 향상하고, Codeberg나 Bitbucket에서는 그 기능 없이도 동작함.

Gerrit UI/UX를 GitHub 리뷰에 가져온 도구인 줄 알았는데 아니어서 아쉬웠음. Gerrit를 떠나 GitHub를 써야 했던 사람에게 그런 UI가 필요함.

내가 만든 목적은 Gerrit UI 복제가 아니라 GitHub에 1커밋=1PR 스택을 얹는 것임. maiao new stack 같은 새 명령은 만들지 않고, 일반 git과 rebase, GitHub API 자동화 위에서 돌게 했음.

기능 브랜치의 커밋마다 PR을 따로 여는 방식은 이해가 안 감. 왜 그렇게까지 해야 하는지 모르겠음.

스택드 디프 세계에서는 리뷰 하나가 커밋 하나인 게 표준임. 1커밋=검토 가능한 단위=PR=변경 목록이라는 방식은 충분히 말이 됨.

활성 커밋자가 10명에서 20명쯤 넘는 팀이면 Gerrit식 체리픽 흐름이 GitHub나 GitLab식 PR 흐름보다 낫다고 봄. 작은 팀은 반대고.

Gerrit UX에는 문제가 있었지만 커밋 단위 리뷰는 훨씬 합리적이었음. 작성자는 rebase로 각 커밋을 고쳐야 해서 기록이 깨끗하고, 큰 GitHub PR에서 댓글이 묻히는 문제도 줄어듦.

내가 jujutsu는 잘 모르지만 maiao는 완전히 git 호환임. 평범한 git commit을 쓰면 각 커밋이 PR이 되고, 베이스가 바뀌면 자동 rebase함.

Adevinta 원본 유지보수자들이 회사를 떠났고 원본 저장소도 더는 활발히 유지되지 않아 커뮤니티 포크가 이어받았음. Runetes는 당시 만든 OSS를 모아 둔 조직임.

주니어는 처음부터 논리적인 단일 커밋을 만들기 어려운데 이 도구가 그걸 해결해 주는지는 의문임. fix, fix of fix가 쌓인 PR을 자주 봄.

리뷰어가 문제 있는 커밋에 squash하라고 댓글을 달고 전후 상태를 비교할 수 있으면 도움이 됨. 커밋을 사소한 이력이 아니라 리뷰 대상 일부로 다루게 됨.

Reviewable.io는 force push가 있어도 모든 변경을 읽게 하고, 댓글 처리 상태도 관리하며, 브랜치 전체를 git만으로 리뷰함. 1 PR=1커밋과 스택 PR은 그런 기능이 부족해서 나온 우회책처럼 보임. 다만 GitHub 전용이고 오픈 소스가 아님.