왜“git push --set-upstream origin

왜“git push --set-upstream origin ”?

---

솔라리스와 썬 스튜디오를 테스트하기 위해 로컬 브랜치를 만들었습니다. 그런 다음 지점을 상류로 밀었습니다. 변경 사항을 커밋하고 변경 사항 푸시를 시도한 후 :

$ 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 : Push a new local branch to a remote Git repository and track it too 에서이 질문과 대답을 따랐 습니다 . 나는 불완전하거나 잘못된 대답의 또 다른 예를 추측하고 있습니다. 또는 간단한 작업을 수행하고 어렵게 만드는 또 다른 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

---

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

---

당신이 질문 - 질문 -is "나는 업스트림을 설정해야합니까"나는 조금 바꿔 수 있습니다에 대한 대답은 : 아니, 당신은하지 않습니다 이없는 전혀 업스트림을 설정할 수 있습니다.

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

여기의 전체 푸시 스토리는 길고 지루하며 Git 버전 1.5 이전으로 거슬러 올라갑니다. 그것을 많이 줄이려면 git push제대로 구현되지 않았습니다. ¹ Git 버전 2.0부터 Git에는 push.default이제 기본값 인 구성 노브가 simple있습니다. 전 2.0 이후 망할 놈의 여러 버전의 경우는 실행 때마다 git push, 힘내 소음 설정을 설득하려고 많이 분출 것이다 push.default단지 얻기 위해 git push최대 종료합니다.

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

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

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

모든 분기는 하나의 업스트림 세트를 가질 수있는 옵션이 있습니다. 즉, 모든 분기에는 업스트림이 있거나 업스트림이 없습니다. 브랜치는 업스트림을 두 개 이상 가질 수 없습니다.

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

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

If your push.default is set to simple or upstream, the upstream setting will make git push, used with no additional arguments, just work.

That's it—that's all it does for git push. But that's fairly significant, since git push is one of the places where a simple typo causes major headaches.

If your push.default is set to nothing, matching, or current, setting an upstream does nothing at all for git push.

(All of this assumes your Git version is at least 2.0.)

The upstream affects git fetch

If you run git fetch with no additional arguments, Git figures out which remote to fetch from by consulting the current branch's upstream. If the upstream is a remote-tracking branch, Git fetches from that remote. (If the upstream is not set or is a local branch, Git tries fetching origin.)

The upstream affects git merge and git rebase too

If you run git merge or git rebase with no additional arguments, Git uses the current branch's upstream. So it shortens the use of these two commands.

The upstream affects git pull

You should never² use git pull anyway, but if you do, git pull uses the upstream setting to figure out which remote to fetch from, and then which branch to merge or rebase with. That is, git pull does the same thing as git fetch—because it actually runs git fetch—and then does the same thing as git merge or git rebase, because it actually runs git merge or git rebase.

(You should usually just do these two steps manually, at least until you know Git well enough that when either step fails, which they will eventually, you recognize what went wrong and know what to do about it.)

The upstream affects git status

This may actually be the most important. Once you have an upstream set, git status can report the difference between your current branch and its upstream, in terms of commits.

If, as is the normal case, you are on branch B with its upstream set to origin/B, and you run git status, you will immediately see whether you have commits you can push, and/or commits you can merge or rebase onto.

This is because git status runs:

• git rev-list --count @{u}..HEAD: how many commits do you have on B that are not on origin/B?
• git rev-list --count HEAD..@{u}: how many commits do you have on origin/B that are not on B?

Setting an upstream gives you all of these things.

How come master already has an upstream set?

When you first clone from some remote, using:

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

or similar, the last step Git does is, essentially, git checkout master. This checks out your local branch master—only you don't have a local branch master.

On the other hand, you do have a remote-tracking branch named origin/master, because you just cloned it.

Git guesses that you must have meant: "make me a new local master that points to the same commit as remote-tracking origin/master, and, while you're at it, set the upstream for master to origin/master."

This happens for every branch you git checkout that you do not already have. Git creates the branch and makes it "track" (have as an upstream) the corresponding remote-tracking branch.

But this doesn't work for new branches, i.e., branches with no remote-tracking branch yet.

If you create a new branch:

$ git checkout -b solaris

there is, as yet, no origin/solaris. Your local solaris cannot track remote-tracking branch origin/solaris because it does not exist.

When you first push the new branch:

$ git push origin solaris

that creates solaris on origin, and hence also creates origin/solaris in your own Git repository. But it's too late: you already have a local solaris that has no upstream.³

Shouldn't Git just set that, now, as the upstream automatically?

Probably. See "implemented poorly" and footnote 1. It's hard to change now: There are millions⁴ of scripts that use Git and some may well depend on its current behavior. Changing the behavior requires a new major release, nag-ware to force you to set some configuration field, and so on. In short, Git is a victim of its own success: whatever mistakes it has in it, today, can only be fixed if the change is either mostly invisible, clearly-much-better, or done slowly over time.

The fact is, it doesn't today, unless you use --set-upstream or -u during the git push. That's what the message is telling you.

You don't have to do it like that. Well, as we noted above, you don't have to do it at all, but let's say you want an upstream. You have already created branch solaris on origin, through an earlier push, and as your git branch output shows, you already have origin/solaris in your local repository.

You just don't have it set as the upstream for solaris.

To set it now, rather than during the first push, use git branch --set-upstream-to. The --set-upstream-to sub-command takes the name of any existing branch, such as origin/solaris, and sets the current branch's upstream to that other branch.

That's it—that's all it does—but it has all those implications noted above. It means you can just run git fetch, then look around, then run git merge or git rebase as appropriate, then make new commits and run git push, without a bunch of additional fussing-around.

---

¹To be fair, it was not clear back then that the initial implementation was error-prone. That only became clear when every new user made the same mistakes every time. It's now "less poor", which is not to say "great".

²"Never" is a bit strong, but I find that Git newbies understand things a lot better when I separate out the steps, especially when I can show them what git fetch actually did, and they can then see what git merge or git rebase will do next.

³If you run your first git push as git push -u origin solaris—i.e., if you add the -u flag—Git will set origin/solaris as the upstream for your current branch if (and only if) the push succeeds. So you should supply -u on the first push. In fact, you can supply it on any later push, and it will set or change the upstream at that point. But I think git branch --set-upstream-to is easier, if you forgot.

⁴Measured by the Austin Powers / Dr Evil method of simply saying "one MILLLL-YUN", anyway.

---

A basically full command is like git push <remote> <local_ref>:<remote_ref>. If you run just git push, git does not know what to do exactly unless you have made some config that helps git to make a decision. In a git repo, we can setup multiple remotes. Also we can push a local ref to any remote ref. The full command is the most straightforward way to make a push. If you want to type fewer words, you have to config first, like --set-upstream.

---

The difference between
git push origin <branch>
and
git push --set-upstream origin <branch>
is that they both push just fine to the remote repository, but it's when you pull that you notice the difference.

If you do:
git push origin <branch>
when pulling, you have to do:
git pull origin <branch>

But if you do:
git push --set-upstream origin <branch>
then, when pulling, you only have to do:
git pull

So adding in the --set-upstream allows for not having to specify which branch that you want to pull from every single time that you do git pull.

참고URL : https://stackoverflow.com/questions/37770467/why-do-i-have-to-git-push-set-upstream-origin-branch