PR은 정말 좋은 기능이지만 몇 가지 문제가 있다.

보통 PR을 날리면 리뷰를 하고, 리뷰자를 두 명 이상으로 지정한다던가 하는 룰을 만들 수 있다.

또한 승인을 눌러야 머지가 되면서 반영이 되는 것이 일반적인 프로세스이다.

반대로 PR을 하고, 리뷰를 대기하면서 CI가 해결하려고 했던 통합 지연이 발생한다.

업무를 하면서 가장 불편했던 점중 하나가 PR이 그때 그때 리뷰-머지가 되는 것이 아닌데, 작업을 하면서 쌓다보면 PR이 점점 커지는 것이다.

그러다보면 무지성 LGTM이 난무한다. 솔직히 제대로 보는 사람이 잘 없다.

이번 글에서는 이러한 문제점을 해결하기 위한 브랜치 전략으로 Ship / Show / Ask 라는 브랜치 전략에 대해서 설명하려고 한다.

원글은 아래 링크를 참조하면 된다.

https://martinfowler.com/articles/ship-show-ask.html

Ship 방식에서는 변경을 바로 머지한다.

코드 리뷰 요청도 없다.

이러한 변경이 안전하다는 것을 확인하기 위해서 일반적인 CI 기법을 사용한다.

다음과 같은 상황에 좋다.

• 정해진 패턴을 사용한 기능 추가 (이미 익숙하고, 자주 사용되어온)

• 사소한 버그 수정

• 문서 갱신

• 동료 피드백을 반영해서 코드 개선

이 방식은 PR은 날리지만 머지를 바로한다.

변경을 빠르게 적용하면서도, 언제든지 PR을 다시 열어 의견과 대화할 수 있는 여지를 만든다.

다음과 같은 상황에 좋다.

• 코드를 더 좋게 만들기 위해 동료의 의견을 받고 싶을 때 사용

• 새로 사용한 패턴이나 접근법을 보여주고 싶을 때 사용

• 리팩토링한 내용을 공유하고 싶을 때 사용

• 흥미진진한 버그를 어떻게 고쳤는지 보여주고 싶을 때 사용

Ask는 일반적인 PR과 동일한 방식이다.

PR을 날리고, 머지하지 않고 의견을 기다린다.

다음과 같은 상황에 좋다.

• 동작할 지 확인받고 싶을 때

• 새 접근법을 어떻게 느낄지 궁금할 때

• 더 나은 방법을 알고 싶을 때

• 오늘 끝냈다, 내일 머지할 것이다. (일종의 선언)

이 룰들은 일반적으로 우리가 대해왔던 PR-LGTM-Merge로 이어지는 고구마 프로세스와는 관점을 달리한다.

규칙들은 다음과 같다.

• 승인 / 코드 리뷰가 PR을 머지하기 위한 조건이어서는 안된다.

  • LGTM이 머지의 조건이 되면 안된다.

• 본인이 Open한 PR은 본인이 머지한다. 변경에 대해서도 본인이 제어해야 한다.

• 출시 상태를 유지하기 위해 좋은 CI/CD 기법을 사용해야 한다.

• 브랜치는 길지 않게 유지해야한다. (자주 Rebase 해야한다)

원 글에서는 대화에 대해서도 강조한다.

PR이 변경에 대해 논할 수 있는 유용한 방법이긴 하나, 대화를 대체하지는 못한다는 것이다.

그리고 사실 이미 브랜치해서 만들어진 결과는 더 나은 안을 찾기도 힘들다.

브랜치가 길어지고 커질수록 더 어렵다.

그러므로 시작하기 전에 대화해야 더 나은 안을 찾을 수 있다.

즉, PR이전에 의견을 자유롭게 나누는 것이 훨씬 중요하다는 얘기이다.

PR은 정말 좋은 기능이지만 몇 가지 문제가 있다.

보통 PR을 날리면 리뷰를 하고, 리뷰자를 두 명 이상으로 지정한다던가 하는 룰을 만들 수 있다.

또한 승인을 눌러야 머지가 되면서 반영이 되는 것이 일반적인 프로세스이다.

반대로 PR을 하고, 리뷰를 대기하면서 CI가 해결하려고 했던 통합 지연이 발생한다.

업무를 하면서 가장 불편했던 점중 하나가 PR이 그때 그때 리뷰-머지가 되는 것이 아닌데, 작업을 하면서 쌓다보면 PR이 점점 커지는 것이다.

그러다보면 무지성 LGTM이 난무한다. 솔직히 제대로 보는 사람이 잘 없다.

이번 글에서는 이러한 문제점을 해결하기 위한 브랜치 전략으로 Ship / Show / Ask 라는 브랜치 전략에 대해서 설명하려고 한다.

원글은 아래 링크를 참조하면 된다.

https://martinfowler.com/articles/ship-show-ask.html

Ship 방식에서는 변경을 바로 머지한다.

코드 리뷰 요청도 없다.

이러한 변경이 안전하다는 것을 확인하기 위해서 일반적인 CI 기법을 사용한다.

다음과 같은 상황에 좋다.

• 정해진 패턴을 사용한 기능 추가 (이미 익숙하고, 자주 사용되어온)

• 사소한 버그 수정

• 문서 갱신

• 동료 피드백을 반영해서 코드 개선

이 방식은 PR은 날리지만 머지를 바로한다.

변경을 빠르게 적용하면서도, 언제든지 PR을 다시 열어 의견과 대화할 수 있는 여지를 만든다.

다음과 같은 상황에 좋다.

• 코드를 더 좋게 만들기 위해 동료의 의견을 받고 싶을 때 사용

• 새로 사용한 패턴이나 접근법을 보여주고 싶을 때 사용

• 리팩토링한 내용을 공유하고 싶을 때 사용

• 흥미진진한 버그를 어떻게 고쳤는지 보여주고 싶을 때 사용

Ask는 일반적인 PR과 동일한 방식이다.

PR을 날리고, 머지하지 않고 의견을 기다린다.

다음과 같은 상황에 좋다.

• 동작할 지 확인받고 싶을 때

• 새 접근법을 어떻게 느낄지 궁금할 때

• 더 나은 방법을 알고 싶을 때

• 오늘 끝냈다, 내일 머지할 것이다. (일종의 선언)

이 룰들은 일반적으로 우리가 대해왔던 PR-LGTM-Merge로 이어지는 고구마 프로세스와는 관점을 달리한다.

규칙들은 다음과 같다.

• 승인 / 코드 리뷰가 PR을 머지하기 위한 조건이어서는 안된다.

  • LGTM이 머지의 조건이 되면 안된다.

• 본인이 Open한 PR은 본인이 머지한다. 변경에 대해서도 본인이 제어해야 한다.

• 출시 상태를 유지하기 위해 좋은 CI/CD 기법을 사용해야 한다.

• 브랜치는 길지 않게 유지해야한다. (자주 Rebase 해야한다)

원 글에서는 대화에 대해서도 강조한다.

PR이 변경에 대해 논할 수 있는 유용한 방법이긴 하나, 대화를 대체하지는 못한다는 것이다.

그리고 사실 이미 브랜치해서 만들어진 결과는 더 나은 안을 찾기도 힘들다.

브랜치가 길어지고 커질수록 더 어렵다.

그러므로 시작하기 전에 대화해야 더 나은 안을 찾을 수 있다.

즉, PR이전에 의견을 자유롭게 나누는 것이 훨씬 중요하다는 얘기이다.