I'd like to know How to find remote branch which will be pushed by origin
git remote
origin
git remote -v
origin https://github.com/test/app (fetch)
origin https://github.com/test/app (push)
I cloned
from develop
branch in app
git clone -b develop https://github.com/test/app
After that
git checkout -b event-api
git branch
develop
event-api
And then, I pushed like following.
git push origin event-api
This command pushed event-api
→ develop
But the origin
seems master
branch by git remote
①Why this command push to `develop` branch instead of master ?
②And How can I detect which branch will be pushed ?
If someone has opinion,please let me know.
Thanks
The git push
command actually takes this as an argument. Let's start with a more detailed command:
git push origin event-api:abc
This tells your Git that it should:
origin
;event-api
branch, by that commit's hash ID;abc
to the commit offered in step 2. That is, when you run git push
, it's your Git that decides what to ask of the other Git.
Now, if you leave out the colon:
git push origin event-api
you might sensibly ask: which branch is my Git going to ask their Git to set?
The answer is complicated. However:
This command pushed
event-api
→develop
I have trouble believing this—to believe it, I'd have to see the exact output from your git push
command.
Here is what the git push
documentation has to say about this kind of git push
. Note that the event-api
string, despite the lack of a colon and a second name, is a refspec in Git terms, and the paragraph quoted here talks about how refspecs are treated:
The <dst> tells which ref on the remote side is updated with this push. Arbitrary expressions cannot be used here, an actual ref must be named. If
git push [<repository>]
without any<refspec>
argument is set to update some ref at the destination with<src>
withremote.<repository>.push
configuration variable,:<dst>
part can be omitted—such a push will update a ref that<src>
normally updates without any<refspec>
on the command line. Otherwise, missing:<dst>
means to update the same ref as the<src>
.
So, before we can say what :<dst>
your Git will fill in, we must ask whether you have a configured remote.origin.push
setting. If you do , that determines which :<dst>
is implied.
Most people don't have any such settings. You have to be something of a Git guru just to find the information in the git config
documentation , or to understand the paragraph quoted above, to know that there is such a variable.
If you don't have this set, which is what I suspect, then git push origin event-api
is simply shorthand for git push origin event-api:event-api
. That is, your Git asks their Git to set (or create) their event-api
branch.
If you run:
git push
without writing out origin
and event-api
, or:
git push origin
without writing out event-api
, another set of rules take over. Here, the most important questions—or at least the first two to ask—are: What Git version are you running? and Have you set push.default
?
The push.default
setting in Git version 2.0 or later is simple
. With simple
, your initial push must generally use git push -u
; after that, git push
behaves sensibly, pushing your event-api
to their event-api
. The reasons for this are a bit complicated, and you can choose other settings. But in Git versions predating 2.0, which are still the standard versions installed by some Linux distributions, the default push.default
setting is matching
.
With the matching
setting, a git push
that omits the name(s) of what branch or branches to push works by having your Git ask the other Git which branches they have. Let's say they have exactly two branch names, master
and develop
, while you have three branch names, master
, develop
, and event-api
. So their Git will list out master
and develop
. Your Git then goes through your three names and matches each against the two names they sent. The result is the two names they sent.
(If you had deleted your master
and/or develop
—which is something you can do; there's no requirement that your Git have any branch names in particular—then you'd have one or zero matching names in this step. But presumably you have these three names, and they probably have just those two.)
Your Git will now, in step 2, offer the last commit on your master
branch, and offer the last commit on your develop
branch. These are the two matching names, so these are the two commits your Git will offer. Their Git will probably already have those commits, but if they don't, they will, in step 3, ask for those commits, and any other commits required to support those commits.
In any case, having gotten through steps 2 and 3, your Git will now ask the other Git to set its master
and its develop
to the two hash IDs from your own Git's master
and develop
respectively. If this makes no changes, you see nothing at all here, but if you did have new commits for them, your Git will send those commits in step 3, and you will see one or both names get updated in step 4.
Remember these things about git push
:
Your Git calls up another Git. To do this, it needs a URL. You will generally use a name like origin
here; origin
is a remote and a remote stores a URL.
Your git push
then pushes commits . Specifically, your Git needs commit hash IDs. Your Git gets these hash IDs from your branch names, which need not match the other Git's branch names. We humans tend to use matching branch names for our own sanity: Git doesn't really care, but we do.
Having sent some commit or commits if needed, your git push
ends by sending the other Git one of the following:
In all three cases, they tell your Git whether they did it, and if not, why not (which your Git prints as a "rejected" error).
The arguments in git push remote refspec...
are the remote , which supplies the URL, and the refspecs (one or more of them), which supply both the local commit hash ID—based on a name, usually, but you can use a raw hash ID if you want—and the name they should set on their end.
(If you do use a raw hash ID, you may have to send a fully-qualified name, like refs/heads/event-api
, as there's now no easy way for your own Git to guess whether you mean the name as a branch name, a tag name, or some other kind of name.)
If you omit the colon in a refspec, the branch name your Git will ask their Git about is normally the same name you used . However, several configuration settings, such as setting push.default
to upstream
, can change this. If you do use the upstream
setting, the control here is what you have set for the branch's upstream . See Why do I have to "git push --set-upstream origin <branch>"?
git branch -r
git branch commands’ various options. -a shows all local and remote branches, while -r shows only remote branches.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.