Git pull without checkout?

I'm used to running git pull and other commands from within a branch I'm working on. But I have set up a development server that several people work on, so I don't want to have to switch branches when I do it. If I want to update an existing branch on the dev server from the github repository we all use, what would be the right way to do that? If I run the command 'git pull github branchname' will that simply pull the branch into the current branch?

All of the git examples I can find seem to indicate that you run 'checkout branchname' first, then do the pull. I'm trying to avoid that. As I said, this is an existing branch and I just want to update to the latest version.

Solution 1:

I was looking for the same thing and finally found the answer that worked for me in another stackoverflow post: Merge, update, and pull Git branches without using checkouts

Basically:

git fetch <remote> <srcBranch>:<destBranch>

Solution 2:

I had the very same issue with necessity to commit or stash current feature changes, checkout master branch, do pull command do get everything from remote to local master workspace, then switch again to a feature branch and perform a rebase to make it up-to-date with master.

To make this all done, keep the workspace on feature branch and avoid all the switching, I do this:

git fetch origin master:master

git rebase master

And it does the trick nicely.

Solution 3:

If you want the local branch tips to get re-pointed after git fetch, you need some additional steps.

More concretely, suppose the github repo has branches D, B, C, and master (the reason for this odd branch-name-set will be clear in a moment). You are on host devhost and you are in a repo where origin is the github repo. You do git fetch, which brings over all the objects and updates origin/D, origin/B, origin/C, and origin/master. So far so good. But now you say you want something to happen, on devhost, to local branches D, B, C, and/or master?

I have these obvious (to me anyway) questions:

1. Why do you want the tips of all branches updated?
2. What if some branch (e.g., B) has commits that the remote (github) repo lacks? Should they be merged, rebased, or ...?
3. What if you're on some branch (e.g., C) and the work directory and/or index are modified but not committed?
4. What if the remote repo has new branches added (A) and/or branches deleted (D)?

If the answer to (1) is "because devhost is not actually for development, but rather is a local mirror that simply keeps a locally-available copy of the github repo so that all our actual developers can read from it quickly instead of reading slowly from github", then you want a "mirror" rather than a "normal" repo. It should not have a work directory, and perhaps it should not accept pushes either, in which case the remaining questions just go away.

If there is some other answer, (2-4) become problematic.

In any case, here's a way to tackle updating local refs based on remote refs (after running git fetch -p for instance):

for ref in $(git for-each-ref refs/remotes/origin/ --format '%(refname)'); do
    local=${ref#refs/remotes/origin/}
    ... code here ...
done

What goes in the ... code here ... section depends on the answers to questions (2-4).