이전에 SAE을 사용하면서 svn에 대해 조금 알게 되었는데, 나중에 Git가 더 고급이라는 것을 알게 되었어요. 그러다가 오랫동안 등록하지 않았던 Github 계정을 꺼냈어요. 시간을 갖고 만지작거려서 pull request에 대해 매우 혼란스러워졌습니다.
업데이트:
[이전초] 당기면 당기는 거겠죠? 아무리 생각해도 푸시 요청처럼 느껴집니다.
[다음초] 아! 작성자를 위한 당김입니다. . .
두 가지가 서로 아무런 관련이 없다는 뜻입니다. 하나는 CLI의 명령이고 다른 하나는 Github의 개념적인 것입니다.
仅有的幸福2017-04-28 09:08:25
더 명확하게 말씀드리자면, 이전 답변과 토론은 그럴듯하며 진실을 가리키는 것이 아닙니다.
풀 리퀘스트와 Github의 git pull는 완전히 무관한 것은 아니지만, 가장 가까운 관계는 또 다른 명령어 git request-pull입니다.
먼저 개념 설명부터 말씀드리겠습니다. 아마도 대부분의 사람들(주제 포함)은 다음과 같이 풀 리퀘스트를 이해할 것입니다.
변경 사항을 업스트림(일반적으로 포크 소스)에 통합하기 위해 풀 요청을 제출합니다.
이 경우에는 푸시 요청이 가장 적절하다고 생각합니다. 이 작업은 전적으로 제가 주도한 작업이기 때문입니다!
그러나 이러한 이해는 업스트림으로 푸시할 권한이 있습니까?라는 전제를 무시합니다. 즉, 업스트림을 직접 작성할 수 있나요?
이것은 두 가지 상황으로 나뉩니다(두 가지 Git 기반 워크플로에 해당).
결국 이러한 오해는 풀 요청 워크플로가 어떻게 작동하는지에 대한 완전한 이해 부족에서 비롯됩니다. 풀 요청 작업에 대한 올바른 설명은 다음과 같아야 합니다.
요청을 시작합니다(Github의 경우 해당 API를 호출한 후 Github이 이를 백엔드에서 실행하는 HTTP 요청입니다
git request-pull, 자세한 내용은 아래 참조). 이 요청은 (HTTP 요청의 요청) ) 은 (풀 요청의 요청) 업스트림 작성자에게 내 포크의 변경 사항을 풀 (풀 요청) 에 대한 요청입니다.
올바른 이해입니다.
마지막으로 이야기 나눠보겠습니다git request-pull. 풀 요청 요청을 하면 git request-pull 하위 명령이 실제로 백그라운드에서 실행됩니다. 이 하위 명령의 (주) 서명은 다음과 같습니다.
이 명령은 변경 사항(커밋의) 요약과 이를 가져오는 데 사용되는 URL을 생성합니다. 요약은 고정 형식 일반 텍스트로 stdout에 출력되며, 후속 처리를 위해 코드를 리디렉션하고 작성할 수 있습니다. 이것이 Github이 각 풀 리퀘스트를 분석하는 방법이므로 해당 커밋, 시간, 작성자 및 기타 정보를 확인할 수 있습니다.
업스트림 작성자가 풀 요청을 받은 후 요청을 수락하기로 선택하면 Github은 git pull을 호출하여 지정된 주소(git request-pull에서 생성된 정보에 포함됨)에서 코드를 가져옵니다. 업스트림 작성자는 당연히 업스트림 repo에 쓸 수 있는 권한을 가지므로 완전한 프로세스가 실현될 수 있습니다.
공식 Git 매뉴얼, 특히 Distributed Git - Contributing to the project을 읽어보는 것이 좋습니다. 이 장을 읽으면 많은 이점을 얻을 수 있을 것입니다.
世界只因有你2017-04-28 09:08:25
공공 도서관이죠? 수정 사항을 이 라이브러리로 가져오면 이 라이브러리의 작성자가 귀하의 요청을 보고 원래 라이브러리에 병합할지 여부를 결정할 수 있습니다.
