In Git, a branch is just an ordered list of commits (a.k.a.: checkins). Something that can be a bit confusing for new users is that branches don't need to have a name (although in most circumstances you want one); and there is nothing particularly special about any particular branch (the master branch is just the default one that's created for you when you initialize a repository).

You probably already know this, but Git is different than some other version control systems like the popular "Subversion", because every "working copy" (in Subversion language) is a repository of it's own... in fact, there is nothing particularly special about any particular copy; except that one copy has been generally agreed-upon as the "canonical" one that is used to store the final product.

So, back to your question... the "canonical" repository that you cloned when you started your local copy contained a "master" branch by default; and it's stuck around. Now, if you had access to the computer that contains the master repository you could log in and run:

git branch -d master

However, if you aren't able to do that, you can still do it from your local machine. The git branch command has a -r option which affects the remote repository. In other words, running the following command should work:

git branch -d -r master

Note that in both of those cases; I am assuming that master has been completely merged into the development history that your local copy is currently sitting at. If you have never used master before (i.e.: you've only ever checked in to development or production), you have nothing to worry about. However, if you (or someone else) has been checking things in to master, then you might have a problem. You can force a delete by changing the -d to -D in the above commands; but I highly recommend checking to see what's in master beforehand! If you don't have access to the remote computer, you probably won't be able to recover it!

By the way; if you (or anyone else) is new to Git, I highly recommend reading Git from the Bottom Up by John Wiegley. Even though I had used Git a little bit on my own before found this article, I didn't really understand how it worked until I read it. It is quite useful!

You can either git merge master or git rebase master.

If the branch has not been distributed to other people, in this case i would prefer git rebase.

Because git rebase makes it as if the changes on the feature branch were made on top of the changes on the master branch, which makes the version graph simpler.

Rebase

Taking the example from the git rebase manual, git rebase master in branch feature:

      A---B---C feature                             A'--B'--C' feature
     /                   --rebase-->               /
D---E---F---G master                  D---E---F---G master

However, git rebase is only suitable when the branch hasn't been distributed, or there will be confusion and extra work downstream, because the old commits A, B, C are now replaced by new commits A', B', C', plus F and G that were not there before.

The actual result after git rebase master in branch feature is this:

      ( A---B---C ) feature@{1}
       /
      /       A'--B'--C' feature
     /       /
D---E---F---G master

Commits A, B, C are dangling after the rebase, but are reachable through git reflog feature as feature@{1}.

Merge

If someone has pulled your branch, or you have pushed it somewhere, you should merge into it instead, to avoid confusion and extra work on the other end. See Recovering from upstream rebase.

This is the result of git merge master in branch feature:

      A---B---C feature                    A---B---C---M feature
     /                   --merge-->       /       ,---’
D---E---F---G master                 D---E---F---G master

Alternatively, if you git merge feature in branch master, it would look like this:

      A---B---C feature                    A---B---C feature
     /                   --merge-->       /         \
D---E---F---G master                 D---E---F---G---M master