From your feature branch (e.g configUpdate) run:

git fetch
git rebase origin/master

Or the shorter form:

git pull --rebase

Why this works:

• git merge branchname takes new commits from the branch branchname, and adds them to the current branch. If necessary, it automatically adds a "Merge" commit on top.

• git rebase branchname takes new commits from the branch branchname, and inserts them "under" your changes. More precisely, it modifies the history of the current branch such that it is based on the tip of branchname, with any changes you made on top of that.

• git pull is basically the same as git fetch; git merge origin/master.

• git pull --rebase is basically the same as git fetch; git rebase origin/master.

So why would you want to use git pull --rebase rather than git pull? Here's a simple example:

• You start working on a new feature.

• By the time you're ready to push your changes, several commits have been pushed by other developers.

• If you git pull (which uses merge), your changes will be buried by the new commits, in addition to an automatically-created merge commit.

• If you git pull --rebase instead, git will fast forward your master to upstream's, then apply your changes on top.

Case 1: remote/master has everything that local master has

If remote/master contains all of the commits that the local master contains, simply do a git pull:

git checkout master
git pull remote master

You can check if the local master has commits that remote/master doesn't by using the following:

git fetch remote
git log --oneline --graph remote/master..master

That will show you all commits that are contained in master but not in remote/master. If you don't see any output, that means remote/master has everything that the local master has.

Case 2: local master has commits that remote/master doesn't have

If the local master contains commits that remote/master doesn't contain, you'll have to figure out how you want to handle that. Do you want to keep them and merge them with remote/master, or do you simply want to throw them away?

Case 2a: merge/rebase local master commits into remote/master

If you want to keep them, you can either merge or rebase the local master with remote/master:

git checkout master
git fetch <remote>

# Merge remote/master
git merge remote/master

# Or rebase local commits on top instead
git rebase remote/master

# Push the results
git push remote master

Case 2b: throw away local master commits

If you don't want to keep the local commits, then just do a hard reset of the local master to the same point as the remote/master:

git checkout master
git fetch remote
git reset --hard remote/master

Documentation

You can read more about all of these commands from the Git documentation. I also highly recommend the excellent free online Pro Git book, especially chapters 1-3 and 6-6.5.

How I would do this

git checkout master
git pull origin master
git merge test
git push origin master

If I have a local branch from a remote one, I don't feel comfortable with merging other branches than this one with the remote. Also I would not push my changes, until I'm happy with what I want to push and also I wouldn't push things at all, that are only for me and my local repository. In your description it seems, that test is only for you? So no reason to publish it.

git always tries to respect yours and others changes, and so will --rebase. I don't think I can explain it appropriately, so have a look at the Git book - Rebasing or git-ready: Intro into rebasing for a little description. It's a quite cool feature

You can reference those remote tracking branches ~(listed with git branch -r) with the name of their remote.

You need to fetch the remote branch:

git fetch origin aRemoteBranch

If you want to merge one of those remote branches on your local branch:

git checkout aLocalBranch
git merge origin/aRemoteBranch

Note 1: For a large repo with a long history, you will want to add the --depth=1 option when you use git fetch.

Note 2: These commands also work with other remote repos so you can setup an origin and an upstream if you are working on a fork.

Note 3: user3265569 suggests the following alias in the comments:

From aLocalBranch, run git combine remoteBranch
Alias:

combine = !git fetch origin ${1} && git merge origin/${1}

Opposite scenario: If you want to merge one of your local branch on a remote branch (as opposed to a remote branch to a local one, as shown above), you need to create a new local branch on top of said remote branch first:

git checkout -b myBranch origin/aBranch
git merge anotherLocalBranch

The idea here, is to merge "one of your local branch" (here anotherLocalBranch) to a remote branch (origin/aBranch).
For that, you create first "myBranch" as representing that remote branch: that is the git checkout -b myBranch origin/aBranch part.
And then you can merge anotherLocalBranch to it (to myBranch).

You create a merge of your feature branch locally, push the branch you merged to (probably "master") to github. Github will now contain the merge. Then delete your local and remote copy of the feature branch.