왜“git push --set-upstream origin <branch>”해야합니까?


146

Solaris 및 Sun Studio를 테스트하기위한 로컬 브랜치를 만들었습니다. 그런 다음 지점을 업스트림으로 푸시했습니다. 변경을 커밋하고 변경을 시도한 후 :

$ git commit blake2.cpp -m "Add workaround for missing _mm_set_epi64x"
[solaris 7ad22ff] Add workaround for missing _mm_set_epi64x
 1 file changed, 5 insertions(+)
$ git push
fatal: The current branch solaris has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin solaris

왜 이것을 위해 특별한 것을해야합니까?

누군가가 생성 하고 원격으로 <branch>푸시 <branch>한 다음 커밋을위한 <branch>것이 아니라고 주장하는 합리적인 유스 케이스가 <branch>있습니까?


나는이 질문에 따라 Stack Overflow에 대답했다 : 새로운 로컬 브랜치를 원격 Git 저장소로 푸시하고 추적하십시오 . 불완전하거나 틀린 대답의 또 다른 사례를 추측하고 있습니다. 또는 Git의 또 다른 사례는 간단한 작업을 수행하고 어렵게 만듭니다.


다른 머신의 모습입니다. 브랜치는 분명히 존재하므로 작성되고 푸시됩니다.

$ git branch -a
  alignas
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/alignas
  remotes/origin/arm-neon
  remotes/origin/det-sig
  remotes/origin/master
  remotes/origin/solaris


2
감사합니다 @Alexi. 불행히도, 인용 된 dup은 기본적으로 표현되는 말도 안되는 유스 케이스를 설명하지 않습니다. (그들은 수사적인 질문이 아닙니다. UX 디자인의 이유에 진심으로 관심이 있습니다).
jww

1
이것은 구성 가능합니다. 그렇게 git config --add push.default current하면 git push는 필요한 경우 원격 저장소에 자동으로 분기를 만듭니다.
Gogowitsch 2016 년

답변:


271

TL; DR : git branch --set-upstream-to origin/solaris


"업스트림을 설정해야합니까?"라고 다시 말한 질문에 대한 대답은 다음과 같습니다. 아니요, 업스트림을 전혀 설정 하지 않아도 됩니다.

그러나 현재 브랜치에 업스트림이없는 경우 Git은 git push및 다른 명령 의 동작을 변경합니다 .

완전한 푸시 스토리는 길고 지루하며 역사상 Git 버전 1.5 이전으로 되돌아갑니다. 전체를 짧게하기 위해 git push제대로 구현되지 않았습니다. 1 Git 버전 2.0부터 Git의 구성 노브 push.default는 이제 기본으로 설정되어 simple있습니다. 2.0 이전 및 이후의 여러 버전의 Git git push에서는 Git을 실행할 때마다 Git이 많은 소음을 분출 하여 종료 하려고 설정 push.default하도록 git push유도합니다.

실행중인 Git 버전이나 구성 여부는 언급하지 않았 push.default으므로 추측해야합니다. 내 생각 엔 당신이 망할 놈의 버전 2 점-뭔가를 사용하고 있음은 당신이 설정 한 것입니다 push.default하기 simple가 닥쳐 얻을 수 있습니다. 길고 지루한 역사로 인해 어떤 버전의 Git을 가지고 있는지, 무엇이든 push.default설정 한 것이 중요하다면 결국 Git으로부터 또 다른 불만이 있다는 사실은 Git 과거의 실수 중 하나를 피하도록 구성되었습니다.

업스트림이란 무엇입니까?

상류는 단순히 (일반 지역) 지점과 관련된 다른 지점 이름, 일반적으로 원격 추적 브랜치입니다.

모든 브랜치에는 하나의 업스트림 세트가 있습니다. 즉, 모든 지점에는 업스트림이 있거나 업스트림이 없습니다. 브랜치는 업스트림을 둘 이상 가질 수 없습니다.

업스트림 유효한 브랜치 (원격 추적과 같은 또는 로컬과 같은 ) 여야합니다 . 즉, 현재 분기 B 에 업스트림 U있으면 작동 해야 합니다. 작동하지 않으면 ( U 가 존재하지 않는다고 불평하는 경우) 대부분의 Git은 업스트림이 전혀 설정되지 않은 것처럼 작동합니다. 과 같은 몇 가지 명령 은 업스트림 설정을 표시하지만 "gone"으로 표시합니다.origin/Bmastergit rev-parse U git branch -vv

업스트림이 좋은 점은 무엇입니까?

push.defaultsimple또는 로 설정된 경우 추가 인수없이 사용되는 upstream업스트림 설정이 git push작동합니다.

그게 다야. 그게 다야 git push. 그러나 git push단순한 오타가 주요 두통을 유발하는 장소 중 하나 이기 때문에 이는 상당히 중요 합니다.

당신이 경우 push.default로 설정 nothing, matching또는 current, 업스트림을 설정하면 모두에서 아무것도하지 않는다 git push.

(이 모든 것은 Git 버전이 2.0 이상이라고 가정합니다.)

상류는 영향을 미칩니다 git fetch

당신이 실행하는 경우 git fetch추가 인수, 힘내 파악 하는 현재 지점의 상류를 참조하여에서 가져 오기 위해 원격. 업스트림이 원격 추적 분기 인 경우 Git은 해당 원격에서 가져옵니다. (업스트림이 설정되지 않았거나 로컬 브랜치 인 경우 Git은 페치를 시도합니다 origin.)

상류에 영향을 미칩니다 git mergegit rebase너무

추가 인수없이 실행 git merge하거나 실행하면 git rebaseGit은 현재 분기의 업스트림을 사용합니다. 따라서이 두 명령의 사용이 단축됩니다.

상류는 영향을 미칩니다 git pull

어쨌든 2를 사용 해서는 git pull안되지만, git pull사용하는 경우 업스트림 설정을 사용하여 가져올 원격을 찾은 다음 병합하거나 리베이스 할 브랜치를 확인하십시오. 즉, git pull같은 일을 git fetch실제로 왜냐면 실행 git fetch - 그리고 다음과 같은 일을 git merge하거나 git rebase실제로 때문에, 실행 git merge 또는 git rebase.

(일반적으로 적어도 두 단계가 실패 할 때 Git을 충분히 알 때까지 수동으로 두 단계를 수동으로 수행해야합니다.

상류는 영향을 미칩니다 git status

이것은 실제로 가장 중요 할 수 있습니다. 업스트림 세트가 있으면 git status커밋 측면에서 현재 분기와 업스트림의 차이점을보고 할 수 있습니다.

일반적인 경우 B와 같이 업스트림이로 설정된 지점 에 있고를 실행 하면 푸시 할 수있는 커밋이 있는지 또는 병합하거나 리베이스 할 수 있는지 커밋 할 수 있습니다.origin/Bgit status

다음이 git status실행 되기 때문입니다 .

  • git rev-list --count @{u}..HEAD: 당신이 가지고 B있지 않은 커밋은 몇 개 입니까?origin/B
  • git rev-list --count HEAD..@{u}: 당신이 가지고 있지 않은 커밋은 몇 개 입니까?origin/BB

업스트림을 설정하면 이러한 모든 것이 제공됩니다.

어떻게 master이미 업스트림 세트를 가지고 있습니까?

일부 원격 장치에서 처음 복제 할 때 다음을 사용하십시오.

$ git clone git://some.host/path/to/repo.git

Git이 수행하는 마지막 단계는 본질적으로 git checkout master입니다. 해당 지역의 지점 밖이 검사 master- 단지 당신이하지 않는 로컬 분기를 master.

다른 한편으로, 당신 origin/master 방금 복제했기 때문에 라는 이름의 원격 추적 분기가 있습니다.

Git은 " master원격 추적 origin/master과 같은 커밋을 가리키는 새로운 로컬 을 만들고, 당신이있는 동안 업스트림을 master로 설정하십시오 origin/master."

이것은 아직 가지고 있지 않은 모든 지점에서 발생합니다 git checkout. 힘내 분기 만들고 해당 원격 추적 분기를 "추적"(업스트림으로) 만듭니다.

그러나 이것은 새로운 지점, 즉 아직 원격 추적 지점이없는 지점에서는 작동하지 않습니다 .

브랜치 를 생성하는 경우 :

$ git checkout -b solaris

아직은 없다 origin/solaris. 로컬에 원격 추적 분기가 없기 때문에 추적 solaris 할 수 없습니다origin/solaris .

새 브랜치를 처음 푸시 할 때 :

$ git push origin solaris

는 on에 생성 되므로 자체 Git 리포지토리 에도 생성 됩니다. 그러나 너무 늦었습니다. 업스트림이없는 로컬 이 이미 있습니다 . solarisoriginorigin/solarissolaris

Git이 이제 자동으로 업스트림으로 설정해서는 안됩니까?

아마. "불완전하게 구현 됨"및 각주 1을 참조하십시오. 지금 변경 하기 가 어렵습니다 . Git을 사용하는 수백만 개의 스크립트가 있으며 현재 동작에 따라 일부 스크립트가 제대로 작동 할 수 있습니다. 동작을 변경하려면 새로운 주요 릴리스, nag-ware를 사용하여 일부 구성 필드를 설정해야합니다. 요컨대, Git은 자체 성공의 희생자입니다. 오늘날의 실수는 대부분 변경 사항이 보이지 않거나 명확하게 개선되거나 시간이 지남에 따라 천천히 수행되는 경우에만 수정할 수 있습니다.

사실은 오늘하지 않습니다이다 않는 한 사용 --set-upstream또는 -u동안 git push. 그것이 메시지가 말하는 것입니다.

그렇게 할 필요는 없습니다. 위에서 언급했듯이 전혀 할 필요는 없지만 업스트림 을 원한다고 가정 해 봅시다 . 이미 지점 만든 solaris에를 origin이전 추진을 통해, 그리고 같은 git branch출력을 보여줍니다, 당신은 이미 origin/solaris 지역 저장소에.

에 대한 업스트림으로 설정하지 않았습니다 solaris.

첫 번째 푸시가 아닌 지금 설정하려면을 사용하십시오 git branch --set-upstream-to. --set-upstream-to하위 명령은 같은 기존 지점의 이름을 사용 origin/solaris하고, 다른 지점에 현재 지점의 상류를 설정합니다.

그게 전부입니다. 그러나 위에서 언급 한 모든 의미가 있습니다. 그것은 당신이 그냥 git fetch주위를 둘러보고, 달리 git merge거나 git rebase, 또는 적절하게 실행 한 다음, 새로운 커밋을 만들고 실행할 수 있다는 것을 의미합니다 git push.


1 공평하게도, 초기 구현이 오류가 발생하기 쉬운 지 명확하지 않았습니다. 모든 새로운 사용자가 매번 같은 실수를 할 때만 분명해졌습니다. 이제는 "가난하다"는 말은 "위대한 것"이 아닙니다.

2 "Never"는 조금 강력하지만, Git 초보자는 단계를 분리 할 때, 특히 git fetch실제로 수행 한 작업을 보여줄 수있을 때 , 다음에 수행 할 작업 git merge또는 git rebase수행 할 작업 을 볼 수 있을 때 상황을 훨씬 더 잘 이해합니다 .

3 당신이 실행하면 처음 git push 으로 git push -u origin solaris당신이 추가하면, - 즉을 -u깃발 힘내 설정합니다 origin/solaris현재 지점의 상류로하는 경우 (그리고 경우에만) 푸시가 성공합니다. 그래서 당신은 제공해야 -u최초의 푸시. 실제로 나중에 푸시 할 때 제공 할 수 있으며이 시점에서 업스트림을 설정 하거나 변경 합니다. 하지만 git branch --set-upstream-to잊었다면 더 쉽다고 생각 합니다.

4 어쨌든 간단히 "one MILLLL-YUN"이라고 말하는 Austin Powers / Dr Evil 방법으로 측정했습니다.


2
일반적인 경우 {지점 / 푸시 지점 / 사용 지점 생성} 인 경우 새 로컬 지점을 원격 Git 리포지토리푸시하고 실제로 작동하는 것으로 추적하면 안 됩니까? 그리고 누군가 {지점 만들기 / 푸시 지점 / 분기 사용 안함}을 원한다면 --set-upstream /dev/null? 와 같은 특별한 일을하지 않아도됩니다 . 왜 일반적인 경우에 부담이 가해 집니까? 나는 이러한 엔지니어링 및 유용성 결정 중 일부를 이해하지 못합니다.
jww

1
@VonC : 맞습니다. 요점 git push -u이지만 실제로 git push -u는 기본값이어야하거나 적어도 아직 업스트림이없는 경우 기본값 이어야하며 git push --no-set-upstream현재 업스트림이없는 경우가 있어야합니다. 그런 식으로 (알 수없는 이유 :-)).
torek

2
"당신은 Git을"정말 불쾌한 "것으로 기록했기 때문에 이런 질문을 계속합니다." 이런 종류의 추측은 자신에게 맡기십시오. 나는 이런 종류의 질문을 계속해서 나 자신에게 묻기 때문에이 질문을 보았습니다. 저는 세계 최고의 UX 디자이너는 아니지만이 특정 시나리오의 기본 동작이 더 나을 수 있다는 것을 알고 있습니다.
Steven Byks 2016 년

4
@torek-감사합니다. 당신의 대답은 환상적이었습니다. 잘 생각하고, 체계적이고, 유익한 정보를 제공합니다. :-)
Steven Byks

6
이것은 구성 가능합니다. 그렇게 git config --add push.default current하면 git push는 필요한 경우 원격 저장소에 자동으로 분기를 만듭니다.
Gogowitsch 2016 년

31

의 차이
git push origin <branch>
와는
git push --set-upstream origin <branch>
당신이 차이를 느낄 것을 끌어 때 원격 저장소에 잘 모두 밀어하지만 점이다.

당신이 할 경우 :
git push origin <branch>
당길 때해야합니다 :
git pull origin <branch>

그러나 당신이하는 경우 :
git push --set-upstream origin <branch>
다음, 당길 때, 당신은해야합니다 :
git pull

따라서 추가 --set-upstream할 때마다 매번 가져올 분기를 지정할 필요가 없습니다 git pull.


왜 "git push"의 두 버전의 차이점에 대해 알고 싶을 지 모르겠습니다. 무의미한!
Frank Puck

17

기본적으로 완전한 명령은 git push <remote> <local_ref>:<remote_ref>입니다. just을 실행 git push하면 git이 결정을 내리는 데 도움이되는 구성을 설정하지 않은 경우 git은 정확히 무엇을 해야할지 알지 못합니다. git repo에서는 여러 리모컨을 설정할 수 있습니다. 또한 원격 참조에 로컬 참조를 푸시 할 수 있습니다. 전체 명령은 푸시하는 가장 간단한 방법입니다. 더 적은 단어를 입력하려면 --set-upstream과 같이 먼저 구성해야합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.