패치 / diff 검사기

사용법

1. 통합 diff를 상자에 붙여 넣거나 .patch, .diff 파일을 끌어다 놓습니다.
2. 합계를 보고 변경 규모를 파악합니다. 파일 수, 추가·삭제 줄 수, 헝크 수입니다.
3. 표에서 관심 있는 파일을 찾습니다. 이름이 바뀐 파일은 새 경로 옆에 이전 경로가 함께 표시됩니다.
4. git apply를 실행하기 전에 노란색으로 표시된 항목을 확인하십시오. 실패하게 될 이유들입니다.
5. 메일로 받은 패치라면 헝크 경고를 `git apply --check` 결과와 비교해 보십시오. 같은 손상을 더 짧게 알려 줍니다.

자주 묻는 질문

`corrupt patch at line N`은 정확히 무슨 뜻입니까?

헝크 본문이 헤더가 선언한 줄 수와 맞지 않는다는 뜻입니다. @@ -1,4 +1,5 @@ 같은 헤더는 이전 쪽 4줄(문맥 + 삭제)과 이후 쪽 5줄(문맥 + 추가)을 약속합니다. git은 읽으면서 세다가 계산이 어긋나는 순간 멈추고, 잘못된 헤더가 아니라 자기가 도달한 줄 번호를 보고합니다. 원인은 거의 언제나 전송입니다. 메일 클라이언트가 긴 줄을 감쌌거나, 문맥 줄을 표시하는 앞 공백 한 칸을 지워서 한쪽이 모자라게 된 것입니다. 이 도구는 문제의 헝크와 약속한 값, 실제 값을 함께 보여 주므로 대개 손으로 고칠 수 있습니다.

빈 문맥 줄이 왜 그렇게 자주 패치를 망칩니까?

문맥 줄은 앞의 공백 한 칸으로 표시되는데, 바뀌지 않은 빈 줄은 결국 공백 한 칸만 있는 줄이 되기 때문입니다. 눈에 보이지 않고, 아주 많은 도구가 그것을 지웁니다. 저장할 때 끝 공백을 없애는 편집기, 메일 클라이언트, 채팅 앱, 터미널을 거친 복사·붙여넣기가 그렇습니다. 공백이 사라지면 그 줄은 문맥이 아니라 빈 줄로 읽히고, 헝크는 양쪽 모두 한 줄씩 모자라게 됩니다. 화면에서 멀쩡해 보이던 패치가 적용되지 않는 가장 흔한 경로입니다.

이 도구가 패치를 적용하거나 내 파일과 대조해 줍니까?

아니고, 할 수도 없습니다. 이 도구는 패치 자체, 즉 diff 안의 계산만 읽으며 대상 파일에는 접근하지 않습니다. 그것만으로도 손상되거나 망가진 패치는 잡아낼 수 있습니다. 그건 패치 하나만의 성질이기 때문입니다. 다만 문맥 줄이 당신의 작업 트리와 맞는지는 알 수 없으므로, 이 도구가 정상이라고 한 패치도 파일이 그사이 바뀌었다면 `does not apply`로 거부될 수 있습니다. 그 확인에는 파일이 필요하고, 명령은 `git apply --check`입니다.

git 패치 말고 순수한 `diff -u` 출력도 읽을 수 있습니까?

읽을 수 있습니다. git 패치에는 `diff --git` 줄과 index 줄, 이름·모드 변경 정보가 붙고 format-patch라면 메일 헤더까지 붙는데, 있으면 모두 읽습니다. diff -u가 만든 순수한 통합 diff에는 그런 것이 없고 곧바로 `--- ` / `+++ ` 헤더 쌍으로 시작하지만 똑같이 처리합니다. 다만 이름 변경과 모드 변경은 순수 형식에서는 감지할 수 없습니다. 형식 자체에 그것을 표현할 방법이 없기 때문입니다.

여기 줄 수가 GitHub에 표시된 것과 왜 다릅니까?

GitHub도 같은 줄을 세지만 요약이 다를 때가 있습니다. 생성된 파일을 숨기고, 큰 diff를 접고, 바이너리 파일을 합계에서 빼기 때문입니다. 이 도구는 당신이 준 패치 안의 모든 헝크를 세며, 그 값은 `git apply --numstat`이 보고하는 값과 같습니다. 합계가 다르다면 갖고 있는 패치가 변경 전체인지 확인해 보십시오. 커밋 하나짜리 .patch URL은 풀 리퀘스트의 누적 diff와 같지 않습니다.

패치가 어딘가로 전송됩니까?

아닙니다. 텍스트는 이 페이지의 자바스크립트가 해석하며 어디로도 보내지 않습니다. 끌어다 놓은 파일도 브라우저의 파일 API로 읽으므로 마찬가지입니다. 페이지를 연 다음 네트워크를 끊고 diff를 붙여 넣어 보면 그대로 동작하는 것으로 확인할 수 있습니다. 알아 둘 가치가 있습니다. 패치는 리뷰 과정에서 가장 민감한 물건인 경우가 많고, 공개되지 않은 코드를 통째로 담고 있으니까요.

관련 도구