GitHub PR마다 공백 숨기기, 한 번 설정으로 유지하는 법

들여쓰기만 바뀐 PR마다 공백 숨기기를 다시 켜는데, 정작 동료 화면에는 변경 파일 수가 다르게 나온다. 이 설정은 어디에 저장되고 무엇까지 바꿀까?

GitHub PR마다 공백 숨기기, 한 번 설정으로 유지하는 법
세 줄 요약
  • 공백 변경을 매번 숨겼다면 Files changed → Settings → Whitespace changes에서 Always hide를 저장할 수 있다.
  • 현재 diff에서만 공백 변경을 숨기는 옵션과 저장 설정을 유지한 채 잠시 공백을 표시하는 기능도 있다.
  • 공백 필터에 따라 파일 수와 변경 통계가 달라지므로 다른 검토자와 비교할 때는 표시 상태를 맞춰야 한다.

공백을 항상 숨길지 이번 diff에서만 숨길지 고른다

GitHub의 변경 공지에 따르면 PR의 Files changed에서 Settings → Whitespace changes로 들어가 공백 표시 방식을 고를 수 있다.

선택동작
Always show공백 변경을 항상 표시한다.
Always hide공백 변경을 항상 숨긴다.
Hide for this diff only현재 diff에서만 숨긴다.

저장한 선호 설정은 개인별로 여러 PR에 적용된다. 저장소의 다른 검토자에게 같은 화면을 강제하는 팀 설정은 아니다.

공백 필터를 켜면 화면의 변경 통계도 달라진다

공백을 숨긴 상태에서는 All commits 옆에 Hide whitespace 필터가 나타난다. 필터의 X를 누르면 저장 설정을 바꾸지 않고 잠시 공백을 표시할 수 있다. 파일 수와 diff 통계는 현재 표시된 diff를 따른다.

따라서 두 검토자의 화면에서 숫자가 다르다고 곧바로 커밋이 바뀌었다고 판단할 수는 없다. 같은 변경을 비교하는 상황이라면 먼저 공백 필터 상태를 맞추는 편이 좋다. 공백까지 포함한 전체 변경을 살펴볼 때도 일시 표시 기능을 사용할 수 있다.

새 파일과 삭제 파일이 두 열의 폭을 모두 쓴다

분할 화면에서는 새 파일과 삭제 파일이 통합 화면처럼 두 열 전체 폭을 사용한다. 회사가 설명한 효과는 표시 공간 확대와 줄바꿈 감소다. 기존 파일의 모든 변경 화면이 통합 방식으로 바뀐다는 발표는 아니다.

이 변화에는 사용 습관에 따른 평가도 있다. 공식 커뮤니티의 aaronhipple은 공백 설정 저장을 반기면서도, 추가는 오른쪽·삭제는 왼쪽에서 읽던 흐름이 깨진다며 넓어진 표시 방식에 반대했다. 이 이용자에게는 줄바꿈을 줄이는 것보다 추가·삭제의 위치를 유지하는 편이 더 중요했던 셈이다.

새 화면에서는 좌우 위치만 보고 추가·삭제를 판단하기보다 파일의 변경 상태도 함께 읽는 편이 낫다. 긴 줄을 더 넓게 볼 수 있다는 장점과 익숙한 위치가 달라졌다는 점을 함께 고려한 검토 방법이다.

Viewed는 읽은 표시이며, 댓글은 제출해야 공유된다

GitHub의 PR 검토 문서는 파일별로 변경을 읽고 댓글을 남긴 뒤 Viewed를 표시하는 흐름을 설명한다. Viewed는 파일을 접고 진행 상황을 추적하는 기능이며, 이후 파일이 바뀌면 표시가 해제된다.

검토를 시작해 작성한 댓글은 제출 전까지 본인에게만 보인다. 검토를 마쳤다면 요약과 함께 Comment·Approve·Request changes 중 목적에 맞는 방식으로 제출해야 한다. 화면을 다 읽었다는 표시와 변경을 승인한다는 의사 표시는 별개다.

자주 묻는 질문

필터의 X를 누르면 Always hide 설정이 지워지는가?

저장 설정은 유지되며 공백을 일시적으로 표시한다.

Viewed를 누르면 승인까지 끝나는가?

아니다. Viewed는 검토 진행 표시다. 승인은 검토 제출에서 선택한다.

평소 읽기 설정은 저장하되, 변경을 대조할 때는 필터 상태를 맞추고 검토 댓글의 제출까지 마쳐야 한다.