자식 버전 제어의 패치 란 무엇입니까?

자식 버전 제어의 패치 란 무엇입니까?

---

나는 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.
$ 

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

When talking in terms of git, patch file still means the same thing, but using diff + patch yourself would be a nightmare. For example, you will always have to have two versions of the file (or even the whole repository) checked out in order to compare them. Doesn't sound that good, does it? So git takes care of all of the hard work for you - it compares your local file with what is there in the repository you are working with, and can show it to you as a "diff", or apply that "diff" as a patch aka commit your changes, or even let you apply some patch file that you have already. Without going deep into details, in this sense git is absolutely the same as other version control systems like SVN, or even CVS or perforce.

Hope it helps!

---

A patch is a small file that indicates what was changed in a repository. It's generally used when someone from outside your team has read-only access but had a good code change available. He then creates a patch and sends it to you. You apply it and push it to the git repository. Everyone then benefits from the updated version, and the author of the patch didn't need read/write access.

It's really mainly a security thing (at least, that's what people use it for).

---

A patch is a set of differences between one or more files, to show what is different between them. You would typically only generate a patch to show someone what you have changed. An example of when you might do this is when you find and fix a bug in an open source application and then post the fix on their bug tracker.

---

A patch file represents a single set of changes that can be applied to any branch, in any order. By using patch, you will get differences between one or more files. And later, you can apply the differences (patch) to get the changes on new files. There are many uses for a patch in Git. If you have uncommitted changes in your working directory, and you need to get that changes to apply somewhere else, just create a patch and apply the patch.

git diff > mypatch.patch

If you have new files in your repository(untracked), then you should stage the file before creating a patch (don't commit), and use the following command

git diff --cached > mypatch.patch 

You can later apply the patch:

git apply mypatch.patch

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

참고 URL : https://stackoverflow.com/questions/8279602/what-is-a-patch-in-git-version-control