Pull request를 효과적으로 사용하는 방법

최근 github에서 Pull request(이하 pr)에 대해 작성하고 답변하던 도중(kubernetes git-sync pr 주고받은 내용 바로가기) 어떻게 pr을 적는것이 효과적일까에 대해 고민이 많아졌다. 고민과 동시에 구글링을 해봣는데 2015년 github blog에 올라온 좋은 글이 있어 해당 내용을 정리하고자 하여 posting을 하게 되었다.

원글 : How to write the perfect pull request

원글에서는 3가지의 상황에 따라 pr을 작성하는 방법에 대해 소개하였다.

Pull request를 시작하는 방법

- pr을 날리는 목적에 대한 내용을 포함하라.

ex. ...기능을 화면에 간편하게 표시하기 위함.

ex. ...을 작동시키게 하기 위함.

- 왜 이 pr을 생성하게 되었는지에 대한 개요문을 포함하라. reviewer는 history에 대해 잘 모를 수 있다.

- pr은 누구든지 읽을 수 있다. 그러므로 내용과 어조를 나중에 읽는 사람들을 초점에 맞추어 적어라.

- 원하는 피드백이 있다면 명시적으로 적어라.

- 언제 피드백을 원하는지 명시적으로 적어라. 만약 pr에 대한 내용이 개발 진행중이라면 pull request 앞에 [WIP]라고 적는다면 reviewer들은 이에 대해 확실히 이해할 수 있다.(WIP는 Work In Progress, 개발중 이라는 뜻)

- 특정인에 대해 특별히 피드백을 받고 싶다면 @사람을 사용하여 논의해라.

ex. @wonyoung for clarification on this logic

- 특정팀에 대해 특별히 피드백을 받고 싶다면 @팀명을 사용하여 논의해라.

ex. @github/security any concerns?

피드백 하는 방법

- pr을 날리는 목적에 대해 숙지하고 있어야한다.

- 만약 어떤 comment에 대해 극구 반대하는 comment를 달고 싶다면, 진정하고 한번 더 생각해보자.

- 물어라, 하라고 하지말고.(공손한 표현을 써라)

ex. "What do you think about trying...?" // 공손한표현

ex. "Don't do..." // X

- 왜 code가 변경되어야 하는지에 대해 자세히 써라

- 코드를 단순화하거나 개선할 수 있는 방법을 제공하라

- 누군가가 만든 작품을 언급할 때, "멍청한"과 같은 경멸적인 용어를 사용하지 마라

- 겸손한 어투.

ex. “I’m not sure, let’s try…”

- 과장하지 말것.

ex. “NEVER do…”

- skill, 지식, product quality의 향상을 초점에 맞추어 비평할 것.

- 어조를 명확히 하기 위해 아래와 같이 이모지를 사용할 것.

ex. “:sparkles: :sparkles: Looks good :+1: :sparkles: :sparkles:” // looking very good~

ex. “Looks good.” // X

피드백에 응답하는 방법

- 피드백에 대해 감사의 표현으로 이끌어 보자.

- 명확한 질문으로 이끌어 내자.

- 해결법에 도달하기 위해 내린 결정에 대해 설명하자.

- 최대한 모든 comment에 대해 응답하자.

- 만약 혼란이나 논쟁이 증가하고 있다면, 쓰여진 단어가 여전히 의사소통의 가장 좋은 형태인지 자신에게 물어보자. 직접 대면한 다음, 오프라인 토론을 요약으로 게시하는 것도 고려해보자.

2015년에 쓰인 글이지만 아직도 유효한 멋진 조언들이다. 상기 가이드라인을 읽어보면 pr도 하나의 글쓰기과정이라고 여기는 것처럼 보인다. pr이라는 과정은 서로 대면해서 의사소통으로 결정하는 것이 아니기 때문에 더욱 어조에 대해 신경을 많이 쓸 수 밖에 없는데, 똑같은 review라도 읽는사람 입장에서 기분이 상할 수도 있기 때문일 것이라고 생각된다.