Hacker News Reader

Comment by lmm | Hacker News Reader

My awkward git use case: while working on a branch, I frequently want to merge changes from the (upstream, remote) master into my branch. Is there a faster way to do this than switch to master, pull, switch back, merge master?

View on HN

Strictly speaking, you can pull from any remote branch directly:

    git fetch remotename
    git merge remotename/master

But you usually just want to rebase your changes onto the latest HEAD:

    git fetch remotename
    git rebase remotename/master

Merging will place the remote branch's changes after yours, which will make your history a nightmare, especially if you're going to continue working on your branch. Rebasing will place your local branch changes after the latest changes to the main branch.

You can even collapse the first one into a single command: "git pull remotename master"

And the second one too: "git pull --rebase remotename master"

Note that in this case, your remote tracking branches wont be updated, so git status will say you are ahead of the remote, while you are in fact at the same point.

A "git fetch <remote>" would then update the remote tracking branches.

If you are using topic branches, it's bad practice to merge from upstream when it is not necessary [1,2,3], because you clutter your branch with new features that are mostly unrelated to what you are trying to accomplish. Consider merging the specific topic branch that you need rather than 'master'. Alternatively, if nothing depends on your branch yet, you can rebase onto 'master', though this may invalidate earlier testing.

Now to your specific question (fast-forward a local branch without checking it out), you can

    git fetch origin master:master

    git push . origin/master:master

Then you can merge 'master' instead of 'origin/master', thus eliminating the remote URL or "remote-tracking" language from the prepared commit message.

[1] http://gitster.livejournal.com/42247.html

[2] http://lwn.net/Articles/328436/

[3] http://yarchive.net/comp/linux/git_merges_from_upstream.html

Your posts seem to be arguing that you shouldn't be merging branches that are full of experimental crap into your topic branch, you should only merge releases - which I agree with (where I work we use the github-flow where the master branch tracks the release version).

Reply on news.ycombinator.com