Git Branch Strategy: Ship / Show / Ask
들어가며
PR은 정말 좋은 기능이지만 몇 가지 문제가 있다.
보통 PR을 날리면 리뷰를 하고, 리뷰자를 두 명 이상으로 지정한다던가 하는 룰을 만들 수 있다.
또한 승인을 눌러야 머지가 되면서 반영이 되는 것이 일반적인 프로세스이다.
그러나 Ready to ship이 약해졌다.
반대로 PR을 하고, 리뷰를 대기하면서 CI가 해결하려고 했던 통합 지연이 발생한다.
업무를 하면서 가장 불편했던 점중 하나가 PR이 그때 그때 리뷰-머지가 되는 것이 아닌데, 작업을 하면서 쌓다보면 PR이 점점 커지는 것이다.
그러다보면 무지성 LGTM이 난무한다. 솔직히 제대로 보는 사람이 잘 없다.
이번 글에서는 이러한 문제점을 해결하기 위한 브랜치 전략으로 Ship / Show / Ask 라는 브랜치 전략에 대해서 설명하려고 한다.
원글은 아래 링크를 참조하면 된다.
Ship
Ship 방식에서는 변경을 바로 머지한다.
코드 리뷰 요청도 없다.
이러한 변경이 안전하다는 것을 확인하기 위해서 일반적인 CI 기법을 사용한다.
다음과 같은 상황에 좋다.
정해진 패턴을 사용한 기능 추가 (이미 익숙하고, 자주 사용되어온)
사소한 버그 수정
문서 갱신
동료 피드백을 반영해서 코드 개선
Show
이 방식은 PR은 날리지만 머지를 바로한다.
변경을 빠르게 적용하면서도, 언제든지 PR을 다시 열어 의견과 대화할 수 있는 여지를 만든다.
다음과 같은 상황에 좋다.
코드를 더 좋게 만들기 위해 동료의 의견을 받고 싶을 때 사용
새로 사용한 패턴이나 접근법을 보여주고 싶을 때 사용
리팩토링한 내용을 공유하고 싶을 때 사용
흥미진진한 버그를 어떻게 고쳤는지 보여주고 싶을 때 사용
Ask
Ask는 일반적인 PR과 동일한 방식이다.
PR을 날리고, 머지하지 않고 의견을 기다린다.
다음과 같은 상황에 좋다.
동작할 지 확인받고 싶을 때
새 접근법을 어떻게 느낄지 궁금할 때
더 나은 방법을 알고 싶을 때
오늘 끝냈다, 내일 머지할 것이다. (일종의 선언)
규칙
이 룰들은 일반적으로 우리가 대해왔던 PR-LGTM-Merge로 이어지는 고구마 프로세스와는 관점을 달리한다.
규칙들은 다음과 같다.
승인 / 코드 리뷰가 PR을 머지하기 위한 조건이어서는 안된다.
LGTM이 머지의 조건이 되면 안된다.
본인이 Open한 PR은 본인이 머지한다. 변경에 대해서도 본인이 제어해야 한다.
출시 상태를 유지하기 위해 좋은 CI/CD 기법을 사용해야 한다.
브랜치는 길지 않게 유지해야한다. (자주 Rebase 해야한다)
대화
원 글에서는 대화에 대해서도 강조한다.
PR이 변경에 대해 논할 수 있는 유용한 방법이긴 하나, 대화를 대체하지는 못한다는 것이다.
그리고 사실 이미 브랜치해서 만들어진 결과는 더 나은 안을 찾기도 힘들다.
브랜치가 길어지고 커질수록 더 어렵다.
그러므로 시작하기 전에 대화해야 더 나은 안을 찾을 수 있다.
즉, PR이전에 의견을 자유롭게 나누는 것이 훨씬 중요하다는 얘기이다.
Last updated