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
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 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!
If you're going to use positional parameters in git aliases, be sure to specify
sh -c. The following worked for me locally:
ff = !sh -c 'git checkout master && git merge "$1" && git checkout "$1"' -
The "why" relates to the way git parses the alias commands and is summed up in this gmane thread.
- at the end of the command signals
sh that option processing is finished. From
A -- signals the end of options and disables further option processing. Any arguments after the -- are treated as filenames and arguments. An argument of - is equivalent to --.
If it weren't present, it would introduce a bug in the alias, by treating
$1 as an option on the
sh command instead of as a positional argument. Consider this trivial example:
$ sh -c 'echo $1' foo # equivalent to 'echo' without argument
$ sh -c 'echo $1' - foo # will pass 'foo' to the string as $1
In the first case, 'foo' was consumed by
sh as an option. In the second, it's correctly interpreted as
$1 on the string.
Git supports this command:
Check out the
origin/masterbranch and then reset