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

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.

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.

If you want to merge your branch to master on remote, follow the below steps:

1. push your branch say 'br-1' to remote using git push origin br-1.
2. switch to master branch on your local repository using git checkout master.
3. update local master with remote master using git pull origin master.
4. merge br-1 into local master using git merge br-1. This may give you conflicts which need to be resolved and changes committed before moving further.
5. Once merge of br-1 to master on local is committed, push local master to remote master using git push origin master.

Do I never need to merge one remote branch into another?

In fact, you can't do that. Well, you can, sort of, but—well, it's confusing. Let's back up. :-)

Git has some rather poor terminology here. The word branch is ambiguous. Once you get used to all of its different meanings, it's not such a bad name: one says "work on branch X" or "checkout out branch Y" and we all know what we meant, but getting to that point is hard. For more about this, see What exactly do we mean by "branch"? But start with this: Git is mostly about commits. Branch names come in later.

Commits and branch names

The most basic way that Git (and you) can find a commit is by its hash ID, which is guaranteed to be unique to that particular commit. But these hash IDs appear to be random: 26e47e261 comes before 8b026edac but 1f1cddd55 comes after either of those, for instance (these are actual commits in the Git repository for Git). Names, like branch names and remote-tracking names, are there to let Git—and you—find the commits. Each such name remembers exactly one hash ID.

Almost every commit also remembers one or two hash IDs. These are the parent commits of that commit. Git can string these various hash IDs, starting with the one stored in a name and working backwards, into chains of commits:

A  <-B  <-C   <--master

The name master remembers the hash ID of commit C, which remembers the hash ID of commit B, which remembers the hash ID of commit A. A is the very first commit (in this tiny repository with only three commits) so it has no parent and thus ends the chain.

The process of adding a new commit consists of writing out the new commit, using the current end-of-branch-chain hash ID as its parent, and then making the name point to the new commit:

A--B--C--D   <-- master

(It's easier not to draw the internal arrows, which always point backwards by definition and—unlike branch names—can never be changed once made, so I generally don't draw them.)

Remote-tracking names

When you work with a Git repository, you generally start by getting all the commits from some other, existing, Git repository. The other Git is using its branch names to find these commits. Your Git collects those commits, but your Git is going to give you your branch names, independent of theirs. So your Git needs some other names—names that are not branch names—in order to find their commits. You clone their repository, and your Git renames their master to your origin/master—a remote-tracking name or remote-tracking branch name, which some people call a remote branch name.¹

After the initial clone, which creates origin/*, a git fetch origin will call up the same URL—saved from when you did the clone—to talk to the same Git, collect from it any new commits it may have, and update all your remote-tracking names to match their branch names. So your remote-tracking names automatically follow their branch names. That's their main purpose: to remember which commit their branch names are remembering.

¹"Remote branch name" is probably the worst of all these phrases, not that any of them are great, because Git uses the word remote to refer to a name like origin that you can use to identify the other Git repository. So if you were to go to the Git at the URL listed under your remote.origin.url, and ask it about its branches, you'd get their master, their develop, and so on. These are the branch names on the remote: the remote's branch names. Each one must necessarily be a remote branch name. But they're not in your Git, which has instead names like origin/master and origin/develop. I think calling origin/master a remote-tracking name is the best of these ambiguous phrases: it's your name for their (origin's) master.

Creating a branch name from another name

The last step of git clone is generally git checkout master.² Your Git doesn't have a master yet, so your Git prowls through all the remote-tracking names it has (it just made them)—origin/develop and origin/master and so on—and finds their origin/master. This points to some specific commit, so your Git now creates your master, pointing to the same commit:

A--B--C--D   <-- master (HEAD), origin/master
          \
           E   <-- origin/develop

If you now run git checkout develop, that creates your own develop, pointing to the same commit as origin/develop:

A--B--C--D   <-- master, origin/master
          \
           E   <-- develop (HEAD), origin/develop

Note that HEAD is attached to one of your branch names—that's how Git knows which branch you're on, when you make a new commit.

Let's say you add your own commit to your own master, by doing git checkout master and doing some work. This creates a new, unique-hash-ID commit, and makes your master point to this new commit:

           F   <-- master (HEAD)
          /
A--B--C--D   <-- origin/master
          \
           E   <-- develop, origin/develop

This particular example does not use git merge, which has its own set of complications (I don't want to get into the details here), but the point is simple enough: you always do all your work on your own branches. When you have finished this work, you can then run git push to:

• send commit(s) to the other Git, as necessary; and then
• ask their Git to set their branch name based on what you just sent.

Hence you can now git push origin master to send your new commit F to them, and ask them to make their master point to commit F. If they agree to this, your Git records this update so that you now have:

           F   <-- master (HEAD), origin/master
          /
A--B--C--D
          \
           E   <-- develop, origin/develop

²You can tell your Git to use another name, and if you don't, the other Git tells your Git which name to use, but usually that's master.

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.