cp를 사용하는 것이 더 쉬운데 diff/patch를 사용하는 이유

차이점은 단순히 한 파일을 다른 파일과 비교하는 것보다 더 복잡할 수 있습니다. 전체 디렉토리 계층을 비교할 수 있습니다. GCC에서 버그를 수정하려는 예를 생각해 보세요. 내 변경 사항으로 4~5개의 파일에 한두 줄이 추가되었고 이 파일과 다른 파일에서는 몇 줄이 제거되었습니다. 이러한 변경 사항을 누군가에게(아마도 GCC로) 전달하고 싶다면 내 선택은 다음과 같습니다.

• 전체 소스 트리 복사
• 변경된 파일만 복사
• 내가 변경한 내용만 사용할 수 있습니다.

전체 소스 트리를 복사하는 것은 의미가 없지만 다른 두 가지 옵션은 어떻습니까? 이것이 문제의 핵심입니다. 이제 다른 사람이 나와 동일한 파일을 작업하고 있고 우리 둘 다 누군가에게 변경 사항을 전달한다고 가정해 보겠습니다. 이 사람은 우리가 한 일과 변경 사항이 호환되는지(파일의 다른 부분) 또는 충돌하는지(파일의 같은 줄) 여부를 어떻게 알 수 있습니까? 그는 그것들을 구별할 것입니다! diff는 파일이 서로 어떻게 다른지 그리고 수정되지 않은 소스 파일과 어떻게 다른지 알려줄 수 있습니다. diff가 필요한 경우 diff를 먼저 보내는 것이 더 합리적입니다. 차이점에는 여러 파일의 변경 사항이 포함될 수도 있으므로 총 9개의 파일을 편집했지만 변경 사항을 설명하는 단일 diff 파일을 제공할 수 있습니다.

차이점을 사용하여 과거 기록을 제공할 수도 있습니다. 3개월 전의 변경으로 인해 오늘에서야 발견한 버그가 발생했다면 어떻게 해야 합니까? 오류가 발생한 기간을 좁혀 특정 변경 사항으로 격리할 수 있다면 diff를 사용하여 변경 사항을 "실행 취소"하거나 되돌릴 수 있습니다. 파일만 복사하면 쉽게 할 수 있는 작업이 아닙니다.

파일의 기록을 생성부터 현재까지의 일련의 차이점으로 기록하는 프로그램인 소스 버전 제어에 관한 것입니다. 차이점은 기록을 제공하고(언제든지 파일을 원래대로 다시 만들 수 있음), 무언가를 깨뜨린 책임이 누구인지 알 수 있으며(차이점에는 소유자가 있음) 특정 차이점을 업스트림 프로젝트에 제공하여 쉽게 제공할 수 있습니다. 업스트림 프로젝트에 대한 변경 사항을 커밋합니다. (아마도 내가 많은 변경 사항을 적용했을 때 그들은 하나의 변경 사항에만 관심이 있을 것입니다.)

요약하자면, 그렇습니다. cpAND보다 쉽지만 파일 변경 사항 추적이 중요한 경우보다 AND의 유용성이 더 큽니다.diffpatchdiffpatchcp

패치를 받으면 일반적으로(완전히 동일한 줄을 변경하지 않는 한) 자신이 변경한 파일 집합에 패치를 적용할 수 있습니다.

이 패치에는 이전 버전에 대한 정보가 포함되어 있습니다.그리고파일의 새 상태입니다. 복사된 파일을 받으면 원본 파일이 무엇인지(이전 상태) 알 수 없으며 변경된 파일(또는 파일 집합)에 차이점을 쉽게 적용할 수 없습니다. 따라서 소스 파일 세트의 경우 공간 보존이 아닌 전후 정보가 주요 관심사이다.

(컨텍스트/통합) diff 이전에는 일반적으로 편집기의 지시에 따라 수행되었지만(X 뒤에 줄 삽입, Y 줄 삭제), 이는 해당 지시가 시작된 상태를 아는 경우에만 작동합니다. 따라서 복사 전용 "솔루션"과 동일한 문제입니다.

diff를 사용하면 변경된 내용을 정확히 볼 수 있으므로 diff/patch를 사용하면 누군가가 파일에 불필요한 변경을 하는 것을 방지할 수 있습니다.

요컨대 그렇습니다. YouTube에서 Thinkg Big Larry Wall 비디오를 보면 그는 diff/patch가 어떻게 시작되었고 어떤 문제가 해결되었는지에 대해 이야기합니다. 본질적으로 패치의 유연성과 사람의 가독성을 유지하면서 인터넷을 통한 통신 크기를 줄이는 것에 관한 것입니다.

로컬 시스템에 있고 이러한 사항에 관심이 없다면 트릭을 수행 cp할 것입니다 .rsync