When doing a git fetch the sides get reversed, and normally you also add origin/ (or the name of your remote) in front of the name you want on your side. This means "pack up what I have in my master, call up the remote named origin over the Internet-phone, send him the package, and ask him if he'll make this his master branch." You can also use, on the left, a commit ID or the word HEAD: git push origin HEAD:master means "take whatever commit I'm on now, and ask the remote origin to make that his master". Usually you see this two-names form when pushing: git push origin master:master for instance. One of these is your name-your branch, in your repository-and the other is their name, that is, the name they use for their branch in their repository. The pair usually, but not always, has the same two branch names on both sides of the colon : between them. The "refspec" is, at its second-simplest, just a pair of branch names, like master:master, develop:develop, and the like. I used the word "refspec" above several times, without ever defining it. If, as in your example, you're currently on master and it merges with origin's master, Git will run the git merge step using whatever new stuff it brought in that went under origin/master (note the slash here). For this part, Git cares mightily about which branch you're on now, and which "remote branch" 3 it merges with. (In sufficiently old versions of Git I think the pull command gets more restrictive during the fetch step.)īut, having potentially fetched and updated all the origin/* remote-tracking branches, the pull code moves on to the git merge step. This means that either git fetch (assuming origin) or git fetch origin will update all your remote-tracking branches for origin, provided you are running a reasonably modern (1.8.4 or later) Git. If you don't pass extra arguments, git fetch will fetch the default set of refspecs for the remote, which is normally 2 "all branches". In versions of Git predating 1.8.4, this prevented git fetch from updating any of your remote-tracking branches, but since 1.8.4, explicitly fetching branch br also updates your origin/ br (assuming the remote in question is named origin). For instance, if you git fetch origin br, the fetch step gets the name of the remote ( origin) and br as a "refspec". 1 The pull command passes most of its arguments right through to the fetch step. Remember, git pull is basically shorthand for git fetch followed by git merge. But be prepared for Git documentation to use their terminology. Instead of remote branch, I like to say branch name as seen on the other (remote) Git repository instead of remote-tracking branch name (e.g., origin/master), I call this a remote-tracking name and instead of tracking branch, I use the phrase branch name with an upstream set. Long after I wrote this answer originally, I find these terms just confuse people-including me!-and these days, I prefer my own terminology. Note that these are terms that Git (and ) use. ![]() Sidebar: Make sure you correctly understand the differences between what the Git documentation calls remote branches, remote-tracking branches and tracking branches to take full advantage of the following explanations. The pull command allows options, and many of these have interesting (and confusing and potentially very un-nice) effects. If you hadn't establish that upstream branch relationship when it came to push your ' my_local_branch', then a simple git push -u origin my_local_branch:my_remote_branch would have been enough to push and set the upstream branch.Īfter that, for the subsequent pulls/pushes, git pull or git push would, again, have been enough.The short answer is "no"-or maybe even "no and yes", if one reads only the title of your question-but this is somewhat misleading. In that case: # if you weren't already on my_local_branch branch: ![]() Git already has all the necessary information. That means your branch is already configured with: branch.my_local_branch.remote originīranch.my_local_rge my_remote_branch ( git branch -f -track won't work if the branch is checked out: use the second command git branch -set-upstream-to instead, or you would get " fatal: Cannot force update the current branch.") $ git branch -set-upstream-to my_local_branch origin/my_remote_branch ![]() # OR (if my_local_branch is currently checked out): Git branch -f -track my_local_branch origin/my_remote_branch
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |