git 'pull request'를 'push request'라고 부르지 않는 이유는 무엇입니까?
지점을 공식 저장소와 병합하는 데 사용되는 용어는 '풀 요청'입니다.변경 내용을 공식 저장소로 푸시하도록 요청하고 있는 것 같아서 혼란스럽습니다.
왜 푸쉬 리퀘스트가 아닌 풀 리퀘스트라고 하는 것입니까?
저장소에 코드가 변경되어 대상 저장소로 이동하려는 경우 다음을 수행합니다.
- 는, 「Push」).
git push - 은 사용자의 내용을 Pull], [Pull], [Pull], [Pull]).
git pull다른 리포로부터).
"풀 요청"은 대상 리포지토리에 변경 내용을 가져오도록 요청하는 것입니다.
"push request"는 변경을 푸시하도록 요청하는 대상 저장소가 됩니다.
pull request를 송신할 때는 공식 repo 소유자에게 자신의 repo에서 변경 내용을 추출해 달라고 요청하는 것입니다.따라서 "pull request"입니다.
tl;dr 밀 수 없기 때문에 리포 오너에게 친절하게 요청하면 그들이 리포에 대해 결정을 내릴 수 있습니다.
저장소에 코드를 푸시할 수 있는 사용자
(아마도 악하거나 교육을 받지 못했거나 알려지지 않은) 누군가가 와서 내가 이것을 당신의 마스터 브랜치에 밀어넣고 당신의 모든 코드를 망쳤다고 말할 수 있을까요? 하하하!
물론 당신은 그가 그것을 하는 것을 원하지 않는다.기본적으로는 안전망이 설정되어 있기 때문에 아무도 사용자의 보고서를 푸시할 수 없습니다.다른 사용자를 공동작업자로 설정한 후 다른 사용자가 밀어넣을 수 있습니다.당신은 당신이 믿는 사람들에게 그런 접근권을 줄 것이다.
따라서 공동작업자가 아니라 푸시를 시도하면 권한이 없음을 나타내는 오류가 발생합니다.
그렇다면 어떻게 다른 개발자들이 푸시 허가를 받지 않은 레포에 푸시할 수 있을까요?
모든 사람에게 액세스 권한을 부여할 수는 없지만, 다른 사람에게 아웃렛/엔트리 포인트를 제공하여 '리포 소유자에게 이 코드를 리포에 끌어넣어 달라고 요청'할 수 있도록 해야 합니다.간단히 말해, 레포에 접근할 수 있게 만드는 것만으로, 그들은 그것을 포크할 수 있습니다.자기들 포크에서 변화를 만들어요.변경 사항을 자신의 포크로 밀어 넣습니다.리모트 레포에 들어가면, 다음과 같이 됩니다.
포크로 풀 요구를 하면 업스트림 repo(직접 푸시할 수 없음) 소유자가 풀 요구를 Marge할지 여부를 결정합니다.
다른 각도에서 설명하려면:
pushing은 (보통) 다른 사람의 승인이 필요 없는 것을 말합니다.예를 들어, 자신이 작성한 기능 브랜치에 항상 푸시 할 수 있습니다.
사용자가 직접 만들고 푸시할 수 있는 두 지점 간에 풀 요청을 만들 수 있습니다.당신은 거의 그런 적이 없어요.
저는 큰 기능을 할 때 이미 풀 요청을 승인했지만 까다로운 변경이 필요했기 때문에 기존 지사에 대한 PR을 작성했습니다.
승인이 필요한 경우 강요하지 마십시오.다른 사용자가 원하는 사항:
- 브런치 리뷰
- 승인하다
- 분점을 가져오다
- 그것을 마스터와 합병하다.
(3+4 = git pull)
덧붙여서, 당신은 왜 그것이 '합병 요청'으로 명명되지 않았느냐고 물을지도 모른다.
이것에 대해서 찾은 최선의 대답은, 복수의 기능 브랜치를 가지지 않고, 메인에 직접 커밋을 하는 경우, 머지(자녀를 형성하는 2명의 부모) 커밋을 실시하지 않는 것입니다.모든 커밋은 이전 커밋에 대한 새로운 커밋일 뿐입니다.따라서 'merge commit'이라는 이름은 적용되지 않습니다.
그리고 반관련 질문도 읽어보시길 권합니다. Git push에서는 정확히 어떤 일이 일어날까요? 왜 git push는 git merge와 같지 않은가?
Pull Request: 내 꺼낼 것을 요청합니다.
유감스럽게도 대부분의 답변은 'pull request'가 무엇을 의미합니까?아니면 '밀어넣기'가 무슨 뜻일까요?OP의 질문이 아니라왜 푸쉬 리퀘스트가 아닌 풀 리퀘스트라고 하는 것입니까?
일반적으로 이러한 종류의 질문 교환은 허용되지만, 이 경우 OP가 이러한 질문 교환에 대한 답을 알고 있는 것이 분명하므로 답변하는 것은 큰 도움이 되지 않습니다.
이 용어를 만든 GitHub의 사람들만이 확실히 알고 있다.다만, 이 용어 선택은 「외부에서 레포지토리로의 변경」의 현상에 대해서, 다음과 같은 견해를 반영한 것이 분명하다고 생각된다.유지관리자가 작업(풀)을 수행합니다.
단, 요구도 액션이며, 그 액션의 실행자는 유지관리자가 아니라 송신자(더 많은 액션, 즉 작업을 수행한 사람)입니다.따라서 'pull request'라는 용어는 에이전트가 누구인지에 대해 혼란을 일으킵니다.결국, 요청의 재귀적인 특성 때문에 혼란이 발생합니다.요구는 프라이머리 에이전트에 의한 액션인 동시에 두 번째 에이전트에 의한 향후 액션에 대한 요구입니다.
이 상황은, 「우리의 집을 짓기 위해서 다른 사람에게 돈을 지불했다」대신 「우리의 집을 짓기 위해서」와 같이, 현재의 일반적인 언어 구조(「우리의 집을 짓기 위해서 다른 사람에게 돈을 지불했다」대신 사용)와 매우 유사합니다.
이를 통해 관리업무가 일류의 노동이라는 관점의 정당성 때문에 용어선택이 이루어진다고 결론지을 수 있다.또, 이 용어 선택에 혼란이 생기는 이유는, 비관리직 노동자가 본래 다른 견해를 가지고 있기 때문일 가능성이 있다.
나는 다른 사람에게 무언가를 맡기고 싶다.
저는 밀거나 당길 권한이 없습니다.
소유자/콜라보레이터에게 권한이 있습니다.그들은 밀고 당길 수 있을 뿐만 아니라 당길 수도 있다.나는 밀 수 없다.
그래서 나는 그들에게 나에게서 당기기 동작을 요청한다. 즉, 간접적으로 내가 그들에게 나의 푸시를 받아들이도록 요청한다는 것을 의미한다.
그러니까 밀지 말란 말이야.그냥 당기기 위해서.그리고 밀치는 것을 받아들이기 위해서.
따라서 'pull' 요청입니다.그리고 '밀어붙이는' 요청도 아니다.
이러한 행동에서 중요한 것은 "요청"이라는 단어입니다.또, 「내 일을 맡아 달라고 부탁하고 있습니다만, 받아 주실 수 있습니까?」라고 생각할 수도 있습니다.- 「풀 리퀘스트」
처음에는 조금 헷갈리지만 나중에는 이해가 된다.
이것을 더 잘 이해하고 영원히 기억하기 위해서는, 당신은 그것을 상상해야 한다.
큰 활성 트리를 {저장소로} 상상합니다.트리가 너무 견고하여 브런치를 삽입하거나 새로운 부품을 추가할 수 없습니다.{ symbolizes creating a new branch or you pushing code } 。대신 트리에 브런치를 트렁크로 끌어오거나 변경할 것을 요청해야 합니다.
"pull requests"라는 용어는 분산된 특성에서 파생되었습니다.변경 내용을 저장소에 푸시하는 것(서브버전 등 중앙 집중식 저장소에서 하는 것)이 아니라 변경 내용을 개별적으로 게시하고 유지관리 담당자에게 변경 내용을 가져오도록 요청합니다.그런 다음 유지관리자는 변경 사항을 검토하고 당기기 작업을 수행할 수 있습니다.
즉, 투고하고 싶은 레포에 대한 글을 쓸 수 있는 권한을 가진 사람에게 레포에서 '당기기'를 의뢰하는 것입니다.
Pull requests를 사용하면 GitHub의 저장소에 있는 분기에 푸시한 변경 사항을 다른 사람에게 알릴 수 있습니다.풀 요청이 열리면 변경 내용을 공동작업자와 논의 및 검토하고 변경 내용이 기본 브랜치에 병합되기 전에 후속 커밋을 추가할 수 있습니다.Github 설명
풀 요청이 Repo에 변경을 풀하도록 요청하는 요청을 생성하고 있습니다.
주관적이고 객관적인 것만이 문제가 아닙니다.만약 그것이 실제로 뒤에 숨어있는 밀기 작전이라면 "밀기를 요청합니다"라고 말하는 것도 논리적이다.
큰 이 할 수 없기 입니다.push다른 사람의 리포트에.신, 신, 신, 신, 신, them, them, them, them, them, , them, instead, instead, instead, instead, instead, instead, instead, instead,pull고객님의 지점입니다.
왜 럼,,, 는는 to to to to to to to to to to to to to to to to to to to to to to to to에 할 수 걸까요?push직감적으로, 이러한 접근방식은 매니저가 고객의 요구를 받아들일지 거부할지를 선택할 수 있는 경우에도 의미가 있습니다.push' '거부'를 선택한 pull나의 보고입니다.
,자,자,자꾸나.push 보고가 .
repo A： repoB：
b c
| |
a a
A와 B는 각각 커밋a에 커밋b와 c를 가지고 있습니다.
너는pushA 서 B.두 가지 결과가 있습니다.
- »
git push리고실실 실실실다다A자 B자 B자 B자 B자 B자. - »
git push --force사라졌지만 commit c는 사라졌습니다. 되다
repo A： repoB：
b b
| |
a a
이런 거 하고 싶은 거 아니죠?그래서 다른 방법으로 해야 합니다.
요.push를 들어,은 래, 꼭, 야, 야를 해야 pull 및 get 'repo'를 합니다.
repo A： repoB：
d
|\
b c c
|/ |
a a
이렇게 하면 .push.
Push Request 시스템은 다음과 같습니다.기여자는 먼저 경합을 처리한 후 요청을 합니다.pushoperation을 .★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★업스트림 리포의 관리자는 기여자의 푸시 요청을 수락할지 거부할지를 선택할 수 있습니다.모든 것이 잘 된다.
단, 다른 푸시 요청이 없는 경우에만 작동합니다.
업스트림브런치를 풀하여 경합을 처리한 후 푸시 요구를 작성했다고 합니다.끝났다고 생각하겠지만, 사실은 그렇지 않아요.코드를 풀하고 있을 때 업스트림 repo의 소유자가 새로운 커밋을 한 것을 알게 됩니다.이제 상황은 다음과 같습니다.
repo A： repoB：
d e
|\ |
b c c
|/ |
a a
이제 해. 이제 당신은pull새로운 커밋을 다시 보고하고 새로운 푸시 요청을 합니다.그리고 상류에 새로운 코드가 커밋될 수 있다는 것도 잊지 마세요.이론상으로는 영원히 루프해야 할 수도 있습니다.
그리고 경험적으로, 당신은 마침내 충돌 없이 잘된 푸시 요청을 할 수 있습니다.축하드립니다만, 수백 건의 푸시 요청이 쇄도하고 있습니다.가 다른 먼저 , "푸시 요청"을 .pull ★★★★★★★★★★★★★★★★★」push
따라서 기여가 깔끔하게 작동하려면 요청된 작업이 다음 두 부분으로 구성되어야 합니다.
- 경합을 해소합니다.
- 브런치를 결합합니다.
그리고 그것은 주인이 해야 한다.그렇지 않은 경우 소유자는 다음을 수행해야 합니다.
- 투고자의 새 코드를 승인합니다.
- 컨플릭션을 해소하는 투자의 방법을 승인합니다.
그러나 예시와 마찬가지로 기여자가 충돌을 제거할 때 더 많은 충돌이 발생할 수 있습니다.
so,는,pull당연히 운영이 선택입니다.pull은 하나 하지 않다push탁한한다
내가 바보 같은 용어라고 생각하는 이유는 내가 당신에게 무언가를 밀고 싶다고 생각하고 싶기 때문이고, 반대로 누군가에게 내 첨가물을 뽑아달라고 부탁하지 않기 때문이다.따라서 PUSH REQ로 변경해야 합니다. 제가 액티브 파트이기 때문입니다.화살은 저부터 시작해서 반대쪽 끝에 있는 구피가 아니라 반대쪽으로 갑니다.IMHO.
이렇게 생각해.로컬 저장소 vs 리모트 저장소.
- 로컬에서 푸시하는 경우.(
git push즉, 리모트저장소는 Pulling code from you(Local)입니다.
당신은 무언가를 요구하고 있습니다.그러니 스스로에게 물어보세요
- 원격 저장소 풀 코드를 사용하시겠습니까? - 풀 요청.
git pull은 저장소에서 꺼내는 것을 의미합니다.
git push는 저장소로 푸시하는 것을 의미합니다.
repo 오너에게 저장소에서 꺼낼 수 있는지 물어보는 것은 당연합니다.
올바르지 않습니다. 풀 요청은 저장소로 푸시하도록 요청하는 것을 의미합니다.
이 배경에는 저장소가 기본적으로 명령어의 소유자가 되어 있다고 생각됩니다.그러나 이 경우 저장소로부터의 코드 취득은 다음 단계로 진행됩니다.git push저장소가 소유자일 경우 코드를 사용자에게 전달하는 책임은 전적으로 사용자에게 있습니다.지만아아 아아아다다일관성이 핵심입니다.
허용되는 답변은 "푸시"하면 저장소에 변경을 강제하는 것처럼 들리지만, 요청임을 알 수 없기 때문에 의미가 없습니다.요구는 본질적으로 강요되는 것이 아니다.
Repo측의 입장에서 생각해!!Pull request - 이것은 Git이 Repo에게 당신이 밖에 들어갈 것이 있다고 말하는 것을 의미하기 때문에 repo의 관점에서 그것은 pull이기 때문에 pull request입니다.
설명의 단락이 필요한 용어가 있으면, 그 용어가 직관적이지 않고, 그 선택 이면에 복잡함이나 일방성이 있는 것을 알 수 있습니다.위에 잘 쓰여진 설명이 많아서 더 이상 추가하지는 않겠습니다만, git에서 push and pull이라는 용어에 대한 저의 불만 코멘트를 드리겠습니다.
문에 붙이고 당기는 일반 라벨을 고려합니다.
문을 조작하려는 사람의 눈으로 해석됩니다.
Push라고 하면 Push가 됩니다.
당김이라고 하면 당연히 문을 자기 쪽으로 당길 때 쓰는 손잡이가 있어요.
이제 gitHub가 도어를 제조하고 도어에 "Pull"이라고 쓴 것이 단순히 당신의 끝이 아닌 다른 끝에서 당기기 위한 것이라고 상상해 보세요(일반 세계에서는 그렇게 푸시!).그런 다음 직감적인 사고에 대응하여 도어 당김을 도어 푸쉬로 변환합니다.
이런 혼란으로 이어지는 것은 바로 그런 사고방식이다.
직관적이고 일차적인 해석에 의존하는 우리 뇌의 시스템 1은 분쟁 영역으로 들어갈 것이다.
Git Pull 및 Push 요청에 대한 이 비정상적인 정의를 받아들이기로 선택했을 뿐이며, 일단 생활에서 받아들여지고 다음 단계로 넘어갈 때 많은 예외 중 하나임을 기억한다.
단순히 코드를 풀(복사본 가져오기)하도록 요청하지만 Push에서는 코드를 타겟에 푸시하여 통합하도록 요청하기 때문입니다.
언급URL : https://stackoverflow.com/questions/21657430/why-is-a-git-pull-request-not-called-a-push-request
'programing' 카테고리의 다른 글
| 문자열 앞에 $는 무엇을 의미합니까? (0) | 2023.04.10 |
|---|---|
| prespare For Segue 전달 방법: 객체 (0) | 2023.04.10 |
| 셸: 다른 셸 스크립트에서 셸 스크립트를 호출하려면 어떻게 해야 합니까? (0) | 2023.04.10 |
| VBA 함수에서 결과를 반환하는 방법 (0) | 2023.04.10 |
| 클릭 가능한 라벨이 있는 체크박스를 작성하려면 어떻게 해야 합니까? (0) | 2023.04.10 |