풀 리퀘스트 병합 실패 시 다음과 같은 전략들을 고려할 수 있습니다.
1. 즉시 포기하기 (Give Up Instantly)
-
문제가 스타일 이외의 아키텍처 이해 부족에서 비롯되었다면, 해당 PR을 빠르게 닫습니다.
-
자신의 실수가 아닌 저장소의 불완전한
README, 지저분한 코드, 오래된 문서 등 저장소 버그로 간주합니다. -
관련 버그 리포트를 제출하여 저장소 수정 후 새로운 PR로 다시 시도합니다.
2. 더 작게 나누기 (Take a Smaller Bite)
-
검토자가 일부 변경 사항은 수용하고 다른 부분은 거부할 경우, 거부된 부분을 PR에서 제거합니다.
-
전체 패키지를 한 번에 판매하려 하지 말고, 검토자가 받아들일 준비가 된 만큼만 제공합니다.
-
결과적으로 하나의 PR 대신 여러 개의 작은 PR을 병합하게 되며, 이는 Zerocracy와 같이 병합된 PR마다 보상을 제공하는 환경에서 더욱 유리합니다.
3. 현명하게 비난하기 (Blame Them Wisely)
-
병합 실패의 원인이 기존 코드베이스의 결함(예: 불안정한 테스트)일 수 있습니다.
-
이 경우, 자신의 PR 실패와 연결하지 않고 마치 외부인이 마스터 브랜치에서 버그를 발견한 것처럼 별도의 버그 리포트를 제출합니다.
-
“마스터 브랜치가 녹색인데 어떻게 버그가 있을 수 있는가?”라는 반론에 대비하여 충분한 증거를 수집하는 것이 중요합니다.
4. 다음으로 넘어가기 (Move On)
-
모든 풀 리퀘스트를 병합하려 하지 않는 것이 중요합니다.
-
일부 문제는 당장 해결할 수 없거나 일부 기능은 지금 구현하기에 적절하지 않을 수 있습니다.
-
부정적인 검토 후 PR을 닫는 것은 괜찮으며, 더 쉬운 버그 수정이나 간단한 기능 구현에 시간을 투자하는 것이 현명합니다.
5. 도움을 요청하지 않기 (Don’t Call for Help)
-
문제가 아무리 어렵더라도 동료에게 도움을 요청하지 않습니다.
-
도움을 요청하는 것은 당신의 평판을 손상시키고 신뢰할 수 없는 프로그래머로 비치게 할 수 있습니다.
-
스스로 문제를 해결하는 능력을 보여주는 것이 중요하며, 실패한 PR은 좌절이 아닌 배움의 기회로 삼아야 합니다.