자식 버전 컨트롤의 패치 란 무엇입니까?

나는 git과 version control을 처음 사용하므로 패치가 무엇인지 알아 내려고 노력하고 있으며 git에서 수행하는 나머지 활동과 어떻게 다른가?

패치는 언제 적용합니까? 커밋 할 때마다 발생합니까?

이 블로그 게시물 에서 패치를 만드는 방법 (통신하고 변경하려는 다른 리포지토리 모음)을 볼 수 있습니다.

^{(2008 년 블로그 게시물 " Bioruby with git : 어떻게 작동할까요? ", Jan AERTS가 발행 한 사진 )}

또 다른 구체적인 예로 Git 을 사용 하여 레일에 기여를 참조하십시오 .

오늘날 GitHub 풀 요청은 GitHub 저장소에 패치 를 적용 하는 것을 매우 쉽게 만들어줍니다. 이는 직접 기고자가 아닌 경우에 유용합니다 (즉, 직접 리포지토리에 푸시 할 권한이 없음).
실제로, 최근 GitHub 는 새로운 패치 알림을 개선하기 위해 " Better Pull Request Emails "를 도입했습니다 .

패치 는 패치 파일이라는 별도의 파일에 포함 된 지침에 따라 텍스트 파일을 업데이트하는 Unix 프로그램입니다.

다시 말해서, 명령 또는 파일을 처리하여 무언가에 적용하는 프로그램이있는 파일을 의미 할 수 있습니다.

이제 패치 파일이란 무엇입니까? 두 줄의 텍스트 파일이 있다고 가정 해 봅시다.

This is line A.
This is line B, or otherwise #2.

그런 다음 첫 번째 줄을 변경하면 파일은 다음과 같습니다.

This is SPARTA.
This is line B, or otherwise #2.

파일 내용의 변경 사항을 어떻게 설명 하시겠습니까? 첫 번째 줄은 "이것은 A 행입니다."라고 말할 수 있습니다. "이것은 SPARTA입니다."또는 첫 줄의 마지막 단어 "A"가 다른 단어 "SPARTA"로 대체되었습니다. 그것이 바로 diff 가 우리에게 알려주는 것입니다. 이 파일의 두 가지 버전이 있는데, 하나는 file1.txt라고하고 다른 하나는 file2.txt라고하고 diff를 실행하여 이것을 얻습니다.

$ diff -u file1.txt file2.txt 
--- file1.txt   2011-11-26 11:07:03.131010360 -0500
+++ file2.txt   2011-11-26 11:07:13.171010362 -0500
@@ -1,2 +1,2 @@
-This is line A.
+This is SPARTA.
 This is line B, or otherwise #2.

변경 사항에 대한 설명이 있으면 초기 내용에 적용하고 수정 된 내용을 얻을 수 있습니다. 그리고 "패치"와 같은 프로그램이 이해할 수있는 통합 형식으로 작성된 이러한 변경 사항을 패치 파일이라고합니다. 마치 물고기에게서 물고기를 얻는 방법을 가르쳐주는 사람에게서 물고기를 얻는 대신 물고기를 물에서 직접 파낼 수 있습니다. 이제 file1.txt에 패치를 적용하여 file2.txt와 똑같이 보이도록하겠습니다.

$ cat file1.txt 
This is line A.
This is line B, or otherwise #2.
$ cat file2.txt 
This is SPARTA.
This is line B, or otherwise #2.
$ diff -u file1.txt file2.txt > changes.patch
$ cat changes.patch 
--- file1.txt   2011-11-26 11:09:38.651010370 -0500
+++ file2.txt   2011-11-26 11:07:13.171010362 -0500
@@ -1,2 +1,2 @@
-This is line A.
+This is SPARTA.
 This is line B, or otherwise #2.
$ patch < changes.patch 
patching file file1.txt
$ cat file1.txt 
This is SPARTA.
This is line B, or otherwise #2.
$ 

이 파일의 두 가지 버전 만있는 것이 더 쉽다고 생각할 수 있습니다. 글쎄,이 간단한 경우에 그렇습니다. 그러나 파일이 많고 파일이 매우 크면 전체 사본 두 개가 아닌 몇 줄의 변경 사항을 적용하는 것이 훨씬 효율적입니다.

git과 관련하여 이야기 할 때 패치 파일은 여전히 ​​똑같은 의미이지만 diff + patch를 사용하는 것은 악몽입니다. 예를 들어, 파일을 비교하려면 항상 두 가지 버전의 파일 (또는 전체 저장소)을 체크 아웃해야합니다. 그렇게 들리지 않습니까? 그래서 git은 당신을 위해 모든 노력을 처리합니다-로컬 파일을 작업중 인 저장소에있는 것과 비교하여 "diff"로 표시하거나 "diff"를 patch 일명 변경 사항을 커밋하거나 이미 가지고있는 일부 패치 파일을 적용 할 수도 있습니다. 세부 사항에 깊이 들어 가지 않으면이 git은 SVN 또는 CVS 또는 perforce와 같은 다른 버전 제어 시스템과 완전히 동일합니다.

그것이 도움이되기를 바랍니다!

패치는 리포지토리의 변경 사항을 나타내는 작은 파일입니다. 일반적으로 팀 외부의 누군가가 읽기 전용 액세스 권한을 가지고 있지만 코드를 올바르게 변경할 수있는 경우에 사용됩니다. 그런 다음 패치를 작성하여 사용자에게 보냅니다. 그것을 적용하고 git 저장소로 푸시하십시오. 모든 사람은 업데이트 된 버전의 이점을 누리고 패치 작성자는 읽기 / 쓰기 액세스 권한이 필요하지 않았습니다.

그것은 실제로 주로 보안 문제입니다 (적어도 사람들이 그것을 사용하는 것입니다).

패치 파일은 임의의 순서로 모든 브랜치에 적용 할 수있는 단일 변경 세트를 나타냅니다. 패치를 사용하면 하나 이상의 파일간에 차이가 발생합니다. 나중에 차이점 (패치)을 적용하여 새 파일에서 변경 사항을 가져올 수 있습니다. Git에는 패치가 많이 사용됩니다. 작업 디렉토리에 커밋되지 않은 변경 사항이 있고 해당 변경 사항을 다른 곳에 적용하려면 패치를 만들고 패치를 적용하십시오.

git diff > mypatch.patch

저장소에 새 파일이 있으면 (트래킹되지 않은) 패치를 작성하기 전에 파일을 준비하고 (커밋하지 말 것) 다음 명령을 사용해야합니다.

git diff --cached > mypatch.patch 

나중에 패치를 적용 할 수 있습니다.

git apply mypatch.patch

쓰기 권한이없는 git 저장소를 변경하려면 변경을 수행하고 둘 사이에 패치를 만들고 패치를 적용 할 권한이있는 사람에게 패치를 보내십시오. 변경 사항은 해당 자식 저장소에 추가해야합니다.

패치는 하나 이상의 파일 간의 차이점으로, 파일 간의 차이점을 보여줍니다. 일반적으로 변경 사항을 다른 사람에게 보여주는 패치 만 생성합니다. 오픈 소스 응용 프로그램에서 버그를 찾아 수정 한 다음 버그 추적기에서 수정 사항을 게시 할 때를 예로들 수 있습니다.