diff는 파일의 내용을 비교하고 차이점을 보고하는 셸 명령어이다. diff라는 용어는 명령어의 출력을 식별하는 데 사용되며, 명령어를 실행하는 것을 의미하는 동사로도 사용된다. 파일을 diff 하려면, diff를 실행하여 diff 결과를 만든다.^[1]

일반적으로 이 명령어는 텍스트 파일을 비교하는 데 사용되지만 이진 파일 비교도 지원한다. 입력 파일 중 하나가 비텍스트 데이터를 포함하는 경우, 명령어는 기본적으로 간략 모드로 작동하며 파일이 다른지에 대한 요약 정보만 보고한다. --text 옵션을 사용하면 항상 행 단위 차이를 보고하지만, 이진 데이터는 일반적으로 텍스트처럼 행으로 구조화되어 있지 않기 때문에 출력을 이해하기 어려울 수 있다.^[2]

이 명령어는 주로 두 파일 간의 변경 사항을 분석하기 위한 임시 용도로 사용되지만 특별한 용도로는 patch 명령어와 함께 사용할 패치 파일을 만드는 데 사용된다. – 이 명령어는 diff 출력 보고서를 패치 파일로 사용하도록 특별히 설계되었다. POSIX는 공유 파일 형식을 포함하여 diff 및 patch 명령어를 표준화하였다.^[3]

초기 diff 유틸리티는 1970년대 초 뉴저지주 머레이힐의 벨 연구소에서 유닉스 운영체제를 위해 개발되었다. 이는 1974년에 출시된 유닉스 제5판의 일부였으며,^[4] 더글러스 매킬로이와 제임스 헌트가 작성하였다. 이 연구는 diff의 초기 프로토타입을 개발한 제임스 W. 헌트와 공동 집필한 1976년 논문에 발표되었다.^[5] 이 논문에서 기술된 알고리즘은 헌트-시만스키 알고리즘으로 알려지게 되었다.

매킬로이의 작업은 스티브 존슨의 GECOS 상의 비교 프로그램과 마이크 레스크의 proof 프로그램의 영향을 받았다. proof 역시 유닉스에서 시작되었으며, diff와 마찬가지로 행 단위 변경 사항을 생성했고 프로그램 출력에서 행 삽입 및 삭제를 나타내기 위해 꺾쇠괄호(">" 및 "<")를 사용했다. 그러나 이러한 초기 응용 프로그램에서 사용된 휴리스틱 이론은 신뢰할 수 없는 것으로 간주되었다. diff 도구의 잠재적 유용성으로 인해 매킬로이는 PDP-11 하드웨어의 처리 및 크기 제한 내에서 잘 작동할 수 있는 다양한 작업을 위한 더 강력한 도구를 연구하고 설계하게 되었다. 이 문제에 대한 그의 접근 방식은 앨프리드 에이호, 엘리엇 핀슨, 제프리 울먼, 해럴드 S. 스톤을 포함한 벨 연구소의 개인들과의 협력에서 비롯되었다.

유닉스 환경에서 ed 행 편집기를 사용하면 diff가 기계가 사용할 수 있는 "편집 스크립트"를 생성할 수 있는 자연스러운 능력을 갖추게 되었다. 이러한 편집 스크립트를 파일로 저장하면 원본 파일과 함께 ed에 의해 수정된 파일 전체로 복원될 수 있다. 이는 파일의 여러 버전을 유지하는 데 필요한 보조 기억 장치를 크게 줄였다. 매킬로이는 diff를 위한 포스트 프로세서를 작성하여 다양한 출력 형식을 설계하고 구현하는 것을 고려했으나, diff가 ed 명령어가 허용하는 구문과 역순 입력을 생성하는 책임을 지는 것이 더 검소하고 간단하다고 판단했다.

1984년, 래리 월은 텍스트 파일 패치를 위한 patch 유틸리티를 만들었고(mod.sources 및 net.sources 뉴스그룹에 소스 코드를 공개함^[6][7][8]), diff의 출력과 변경 전 내용을 담은 diff 입력 파일을 사용하여 변경 후 내용이 담긴 파일을 생성했다.

1987년의 X/Open Portability Guide issue 2에 diff가 포함되었다. Context 모드는 POSIX.1-2001(issue 6)에 추가되었다. Unified 모드는 POSIX.1-2008(issue 7)에 추가되었다.^[9]

diff의 초기 시절, 일반적인 용도로는 소프트웨어 소스 코드 및 기술 문서 마크업의 변경 사항 비교, 프로그램 디버깅 출력 검증, 파일 시스템 목록 비교, 컴퓨터 어셈블리 코드 분석 등이 포함되었다. ed를 대상으로 한 출력은 파일에 만들어진 수정 순서에 대한 압축을 제공하기 위해 동기 부여되었다.^[10] 소스 코드 제어 시스템 (SCCS)과 그 수정본을 보관하는 기능은 diff의 편집 스크립트를 저장한 결과로 1970년대 후반에 등장했다.

다른 목적으로 사용되는 편집 거리 개념과 달리 diff는 문자 단위가 아닌 행 단위 지향적이지만, 한 파일에서 다른 파일을 만들기 위해 최소한의 삭제 및 삽입 집합을 결정하려고 한다는 점에서 레벤슈타인 거리와 유사하다.

diff의 작동은 최장 공통 부분 수열 문제 해결을 기반으로 한다.^[5] 이 문제에서, 두 개의 항목 시퀀스가 주어질 때:

a b c d f g h j q z

a b c d e f g i j k r x y z

동일한 순서로 두 원래 시퀀스 모두에 존재하는 가장 긴 항목 시퀀스를 찾으려 한다. 즉, 첫 번째 원래 시퀀스에서 일부 항목을 삭제하고 두 번째 원래 시퀀스에서 다른 항목을 삭제하여 얻을 수 있는 새로운 시퀀스를 찾으려 한다. 또한 이 시퀀스가 가능한 한 길기를 원한다. 이 경우, 결과는 다음과 같다.

a b c d  f  g  j  z

최장 공통 부분 수열로부터 diff와 유사한 출력을 얻는 것은 작은 단계일 뿐이다. 만약 항목이 부분 수열에는 없으나 첫 번째 원래 시퀀스에는 있다면, 그것은 삭제되었음에 틀림없다(아래의 '-' 표시로 나타냄). 만약 부분 수열에는 없으나 두 번째 원래 시퀀스에 있다면, 삽입되었음에 틀림없다(아래의 '+' 표시로 나타냄).

e   h i   q   k r x y
+   - +   -   + + + +

diff 명령어는 diff 원본 새파일과 같이 두 개의 인자를 허용한다. 일반적으로 인자는 각각 일반 파일을 식별하지만, 두 인자가 디렉토리를 식별하면 명령어는 디렉토리 내의 대응되는 파일을 비교한다. -r 옵션을 사용하면 일치하는 하위 디렉토리를 재귀적으로 내려가며 대응되는 상대 경로의 파일을 비교한다.

아래 예시는 원본 파일과 새 파일의 내용 및 기본 형식으로 된 diff 출력 결과를 보여준다. 가독성을 높이기 위해 색상이 적용된 출력을 보여준다. GNU diff는 --color 옵션을 사용하면 출력을 컬러화할 수 있다. --color 옵션이 지정되지 않으면 컬러 출력은 기본적으로 비활성화된다.^[11]

This part of the
document has stayed the
same from version to
version. It shouldn't
be shown if it doesn't
change. Otherwise, that
would not be helping to
compress the size of the
changes.

This paragraph contains
text that is outdated.
It will be deleted in the
near future.

It is important to spell
check this dokument. On
the other hand, a
misspelled word isn't
the end of the world.
Nothing in the rest of
this paragraph needs to
be changed. Things can
be added after it.

This is an important
notice! It should
therefore be located at
the beginning of this
document!

This part of the
document has stayed the
same from version to
version. It shouldn't
be shown if it doesn't
change. Otherwise, that
would not be helping to
compress the size of the
changes.

It is important to spell
check this document. On
the other hand, a
misspelled word isn't
the end of the world.
Nothing in the rest of
this paragraph needs to
be changed. Things can
be added after it.

This paragraph contains
important new additions
to this document.

0a1,6
> This is an important
> notice! It should
> therefore be located at
> the beginning of this
> document!
>
11,15d16
< This paragraph contains
< text that is outdated.
< It will be deleted in the
< near future.
<
17c18
< check this dokument. On
---
> check this document. On
24a26,29
>
> This paragraph contains
> important new additions
> to this document.

이 기본 형식에서 a는 추가(added), d는 삭제(deleted), c는 변경(changed)을 나타낸다. 원본 파일의 행 번호는 단일 문자 코드 앞에 나타나며, 새 파일의 행 번호는 뒤에 나타난다. (추가, 삭제 또는 변경된 행의 시작 부분에 있는) 작음 기호와 큼 기호는 해당 행이 어떤 파일에 나타나는지를 나타낸다. 추가된 행은 원본 파일에 추가된 것이며 새 파일에 나타난다. 삭제된 행은 원본 파일에서 삭제된 것이며 새 파일에는 없다.

기본적으로 양쪽 파일에 공통인 행은 표시되지 않는다. 이동된 행은 새 위치에 추가되고 이전 위치에서 삭제된 것으로 표시된다.^[12] 그러나 일부 diff 도구는 이동된 행을 강조 표시한다.

ed 스크립트는 -e 옵션을 사용하여 최신 버전의 diff로 생성할 수 있다. 이 예제에 대한 결과 편집 스크립트는 다음과 같다.

24a

This paragraph contains
important new additions
to this document.
.
17c
check this document. On
.
11,15d
0a
This is an important
notice! It should
therefore be located at
the beginning of this
document!

.

ed를 사용하여 원본 파일의 내용을 새 파일의 내용으로 변환하려면, 이 diff 파일에 두 행을 추가한다. 한 행은 w (write) 명령어, 다른 한 행은 q (quit) 명령어를 포함한다(예: printf "w\nq\n" >> mydiff). 여기서 diff 파일 이름을 mydiff로 지정하면 ed -s original < mydiff를 실행할 때 변환이 일어난다.

유닉스의 버클리 배포판은 1981년 7월에 출시된 2.8 BSD에서 컨텍스트 형식(-c)을 추가하고 파일 시스템 디렉토리 구조를 재귀적으로 탐색하는 기능(-r)을 추가하였다. 버클리에서 도입된 diff의 컨텍스트 형식은 최소한으로 변경되었을 수 있는 소스 코드에 대한 패치를 배포하는 데 도움이 되었다.

컨텍스트 형식에서 변경된 모든 행은 변경 전후의 변경되지 않은 행과 함께 표시된다. 변경되지 않은 행을 포함하면 패치에 대한 컨텍스트가 제공된다. 컨텍스트는 두 파일 사이에서 변경되지 않은 행들로 구성되며, 행 번호가 여전히 일치하는지 여부와 관계없이 수정된 파일에서 행의 위치를 찾고 변경 사항을 적용할 의도된 위치를 찾는 참조가 된다. 컨텍스트 형식은 인간의 가독성을 향상시키고 패치를 적용할 때의 신뢰성을 높이며, patch 프로그램에 입력으로 허용되는 출력을 제공한다. 이러한 지능적인 동작은 기존의 diff 출력으로는 불가능하다.

변경 덩어리(hunk)의 위와 아래에 표시되는 변경되지 않은 행의 수는 사용자가 정의할 수 있으며, 0으로 설정할 수도 있으나 일반적으로 기본값은 3행이다. 만약 덩어리 안의 변경되지 않은 행의 컨텍스트가 인접한 덩어리와 겹치면, diff는 변경되지 않은 행의 중복을 피하고 덩어리들을 하나의 덩어리로 병합한다.

"!"는 두 파일에서 대응되는 행 간의 변경을 나타내고, "+"는 행의 추가, "-"는 행의 제거를 나타낸다. 빈 공백은 변경되지 않은 행을 나타낸다. 패치의 시작 부분에는 전체 경로와 탭 문자로 구분된 타임스탬프를 포함한 파일 정보가 있다. 각 덩어리의 시작 부분에는 파일의 해당 변경 사항에 적용되는 행 번호가 있다. 별표 3개 집합 사이에 나타나는 숫자 범위는 원본 파일에 적용되고, 대시 3개 집합은 새 파일에 적용된다. 덩어리 범위는 각각의 파일에서 시작 및 종료 행 번호를 지정한다.

diff -c 원본 새파일 명령어는 다음과 같은 출력을 생성한다:

*** /path/to/original	timestamp
--- /path/to/new	timestamp
***************
*** 1,3 ****
--- 1,9 ----
+ This is an important
+ notice! It should
+ therefore be located at
+ the beginning of this
+ document!
+
  This part of the
  document has stayed the
  same from version to
***************
*** 8,20 ****
  compress the size of the
  changes.

- This paragraph contains
- text that is outdated.
- It will be deleted in the
- near future.

  It is important to spell
! check this dokument. On
  the other hand, a
  misspelled word isn't
  the end of the world.
--- 14,21 ----
  compress the size of the
  changes.

  It is important to spell
! check this document. On
  the other hand, a
  misspelled word isn't
  the end of the world.
***************
*** 22,24 ****
--- 23,29 ----
  this paragraph needs to
  be changed. Things can
  be added after it.
+
+ This paragraph contains
+ important new additions
+ to this document.

유니파이드 형식(또는 unidiff)^[13][14]은 컨텍스트 형식의 기술적 개선 사항을 계승하지만, 이전 텍스트와 새 텍스트를 바로 인접하게 배치하여 더 작은 diff를 생성한다. 유니파이드 형식은 보통 "-u" 명령줄 옵션을 사용하여 호출된다. 이 출력은 종종 patch 프로그램의 입력으로 사용된다. 많은 프로젝트에서 "diff"를 유니파이드 형식으로 제출할 것을 특별히 요청하며, 이로 인해 유니파이드 diff 형식은 소프트웨어 개발자 간 교환을 위한 가장 일반적인 형식이 되었다.

유니파이드 컨텍스트 diff는 1990년 8월 웨인 데이비슨에 의해(comp.sources.misc의 14권에 나타난 unidiff에서) 처음 개발되었다. 리처드 스톨먼은 한 달 후 GNU 프로젝트의 diff에 유니파이드 diff 지원을 추가했다. 이 기능은 1991년 1월에 출시된 GNU diff 1.15에서 처음 선보였다. 이후 GNU diff는 컨텍스트 형식을 일반화하여 diff의 임의 서식을 허용하게 되었다.

이 형식은 원본 파일 앞에 "---"가 붙고 새 파일 앞에 "+++"가 붙는 것을 제외하면 컨텍스트 형식과 동일한 2행 헤더로 시작한다. 그 뒤에는 파일의 행 차이를 포함하는 하나 이상의 변경 덩어리(change hunks)가 따른다. 공백 문자가 변경되지 않은 컨텍스트 행 앞에 오고, 더하기 기호가 추가 행 앞에 오며, 빼기 기호가 삭제 행 앞에 온다.

덩어리는 범위 정보(range information)로 시작하며, 행 추가, 행 삭제 및 변경되지 않은 컨텍스트 행 앞에 즉시 위치한다. 범위 정보는 이중 골뱅이표로 둘러싸여 있으며, 컨텍스트 형식(위)에서 두 행에 걸쳐 나타나는 정보를 한 행으로 결합한다. 범위 정보 행의 형식은 다음과 같다:

@@ -l,s +l,s @@ 선택적 섹션 제목

덩어리 범위 정보는 두 개의 덩어리 범위를 포함한다. 빼기 기호는 원본 파일의 덩어리 범위 앞에 오고, 더하기 기호는 새 파일의 범위 앞에 온다. 각 덩어리 범위는 l,s 형식이며, l은 시작 행 번호, s는 각 파일에 대해 변경 덩어리가 적용되는 행 수이다. 많은 GNU diff 버전에서 각 범위는 쉼표와 뒤에 오는 값 s를 생략할 수 있으며, 이 경우 s는 기본값 1이 된다. 첫 번째 범위의 l 행 번호만이 실제로 중요한 값이며, 다른 모든 값은 diff로부터 계산될 수 있음에 유의하라.

원본에 대한 덩어리 범위는 모든 컨텍스트 및 삭제(변경된 행 포함) 덩어리 행의 합이어야 한다. 새 파일에 대한 덩어리 범위는 모든 컨텍스트 및 추가(변경된 행 포함) 덩어리 행의 합이어야 한다. 덩어리 크기 정보가 덩어리의 행 수와 일치하지 않으면 diff는 유효하지 않은 것으로 간주되어 거부될 수 있다.

선택적으로 덩어리 범위 뒤에 덩어리가 속한 섹션 또는 함수의 제목이 올 수 있다. 이는 주로 diff를 읽기 쉽게 만드는 데 유용하다. GNU diff로 diff를 만들 때 제목은 정규 표현식 일치로 식별된다.^[15]

행이 수정되면 삭제 및 추가로 표현된다. 원본 파일과 새 파일의 덩어리가 같은 덩어리에 나타나므로 이러한 변경 사항은 서로 인접하게 나타난다.^[16] 아래 예시에서 이에 대한 예는 다음과 같다:

-check this dokument. On
+check this document. On

diff -u 원본 새파일 명령어는 다음과 같은 출력을 생성한다:

--- /path/to/original	timestamp
+++ /path/to/new	timestamp
@@ -1,3 +1,9 @@
+This is an important
+notice! It should
+therefore be located at
+the beginning of this
+document!
+
 This part of the
 document has stayed the
 same from version to
@@ -8,13 +14,8 @@
 compress the size of the
 changes.

-This paragraph contains
-text that is outdated.
-It will be deleted in the
-near future.
-
 It is important to spell
-check this dokument. On
+check this document. On
 the other hand, a
 misspelled word isn't
 the end of the world.
@@ -22,3 +23,7 @@
 this paragraph needs to
 be changed. Things can
 be added after it.
+
+This paragraph contains
+important new additions
+to this document.

파일 이름과 타임스탬프를 성공적으로 구분하기 위해 탭 문자가 구분 기호 역할을 한다. 이는 화면상에서는 보이지 않으며 콘솔/터미널 화면에서 diff를 복사하여 붙여넣을 때 유실될 수 있다.

특정 프로그램에서 사용되고 이해되는 diff 형식에 대한 몇 가지 수정 및 확장이 존재한다. 예를 들어, 아파치 서브버전과 같은 일부 버전 관리 시스템은 diff의 헤더 섹션에서 타임스탬프 대신 또는 타임스탬프와 함께 버전 번호, "작업 복사본(working copy)" 또는 기타 주석을 지정한다.

일부 도구는 여러 다른 파일에 대한 diff를 하나로 병합할 수 있게 해주며, 각 수정된 파일에 대해 다음과 같은 헤더를 사용한다:

Index: path/to/file.cpp

새줄 문자로 끝나지 않는 파일의 특수한 경우는 처리되지 않는다. unidiff와 POSIX diff 표준 모두 이러한 유형의 파일을 처리하는 방법을 정의하지 않는다(실제로 그러한 파일은 엄격한 POSIX 정의상 "텍스트" 파일이 아니다.^[17]). GNU diff와 깃은 진단으로 "\ No newline at end of file"(또는 번역된 버전)을 생성하지만, 이 동작은 이식성이 없다.^[18] GNU patch는 이 경우를 처리하지 못하는 것으로 보이나, git-apply는 처리한다.^[19]

patch 프로그램이 구현체별 diff 출력을 반드시 인식하는 것은 아니다. 그러나 GNU patch는 깃 패치를 인식하고 조금 다르게 동작한다.^[20]

1975년 이후의 변경 사항에는 핵심 알고리즘 개선, 명령어에 유용한 기능 추가, 새로운 출력 형식 설계 등이 포함된다. 기본 알고리즘은 유진 W. 마이어스의 논문 An O(ND) Difference Algorithm and its Variations^[21]와 웹 밀러 및 마이어스의 A File Comparison Program에서 설명된다.^[22] 이 알고리즘은 에스코 우코넨의 Algorithms for Approximate String Matching에서 독립적으로 발견되고 설명되었다.^[23] 최초의 diff 프로그램 에디션은 새줄 문자가 행을 구분한다고 예상하며 텍스트 파일의 행 비교를 위해 설계되었다. 1980년대까지 이진 파일에 대한 지원이 애플리케이션의 설계와 구현을 변화시켰다.

GNU diff와 diff3는 다른 diff 및 patch 관련 유틸리티와 함께 diffutils 패키지에 포함되어 있다.^[24]

포스트 프로세서인 sdiff와 diffmk는 각각 나란히 배치된 diff 목록과 인쇄 문서에 적용된 변경 표시를 렌더링한다. 둘 다 1981년 이전에 벨 연구소의 다른 곳에서 개발되었다.

Diff3는 두 개의 diff를 조정하여 한 파일을 다른 두 파일과 비교한다. 이는 원래 폴 제이슨이 공통 소스를 편집하는 두 사람에 의해 만들어진 변경 사항을 조정하기 위해 고안되었다. 또한 병합을 위해 RCS와 같은 버전 관리 시스템에서도 사용된다.^[25]

이맥스에는 패치가 제공하는 변경 사항을 패치 파일을 위한 대화형 편집 및 병합 기능을 결합한 사용자 인터페이스로 보여주는 Ediff가 있다.

Vim은 vimdiff를 제공하여 2개에서 8개의 파일을 비교하고 차이점을 색상으로 강조 표시한다.^[26] 역사적으로는 diff 프로그램을 호출했지만, 최신 vim은 향상된 속도와 기능을 제공하는 깃의 xdiff 라이브러리(LibXDiff) 코드를 사용한다.^[27]

GNU Wdiff^[28]는 단어 줄바꿈이나 다른 열 너비가 존재하는 경우에도 문장으로 쓰여진 텍스트 문서에서 변경된 단어나 구를 보여주는 diff의 프론트엔드이다.

colordiff는 'diff'에 대한 펄 래퍼로, 동일한 출력을 생성하지만 추가 및 삭제된 부분에 대해 색상화를 수행한다.^[29] diff-so-fancy와 diff-highlight는 더 새로운 유사 도구이다.^[30] "delta"는 변경 사항과 기본 코드를 동시에 강조 표시하는 Rust 재작성 도구이다.^[31]

Patchutils는 컨텍스트 diff와 유니파이드 diff를 결합, 재배열, 비교 및 수정하는 도구를 포함한다.^[32]

구문 구조에 따라 소스 파일을 비교하는 유틸리티는 주로 일부 프로그래밍 언어에 대한 연구 도구로 구축되었다.^[33][34][35] 일부는 상용 도구로 이용 가능하다.^[36][37] 또한 구문 인식 diff를 수행하는 무료 도구는 다음과 같다:

• C++: zograscope, AST 기반.^[38]
• HTML: Daisydiff,^[39] html-differ.
• XML: 마이크로소프트의 xmldiffpatch 및 IBM의 xmldiffmerge.^[40][41]
• 자바스크립트: astii (AST 기반).
• 다국어: Pretty Diff (코드 서식 지정 후 diff)^[42]

spiff는 부동 소수점 계산의 반올림 오차와 공백의 차이를 무시하는 diff의 변형으로, 둘 다 일반적으로 소스 코드 비교와는 관련이 없다. 벨코어가 초기 버전을 작성하였다.^[43][44] HPUX 포트가 현재 가장 최신의 공개 릴리스이다. spiff는 이진 파일을 지원하지 않는다. spiff는 표준 diff 형식으로 표준 출력에 출력하며 C, 본 셸, 포트란, 모듈라-2, 리스프 프로그래밍 언어로 된 입력을 허용한다.^{[45][46][43][47][44]}

LibXDiff는 1998년부터 많은 알고리즘에 대한 인터페이스를 제공하는 LGPL 라이브러리이다. 라빈 지문을 사용한 개선된 마이어스 알고리즘이 원래 구현되었으나(2008년 최종 릴리스 기준),^[48] 깃과 libgit2의 포크는 이후 자체적으로 많은 알고리즘을 저장소에 확장하였다. "histogram"이라 불리는 알고리즘은 속도와 품질 면에서 원본 마이어스 알고리즘보다 더 낫다고 일반적으로 간주된다.^[49][50] 이는 Vim에서 사용하는 최신 버전의 LibXDiff이다.^[27]

• 버전 관리

• diff: 두 개의 파일 비교 – 명령어와 유틸리티 오픈 그룹의 단일 유닉스 규격, Issue 7 참고

• GNU Diff 유틸리티. 자유 소프트웨어 재단을 통해 이용 가능. 자유 문서. 자유 소스 코드.