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!
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"' -
(dead link)
The "why" relates to the way git parses the alias commands and is summed up in this gmane thread.
The -
at the end of the command signals sh
that option processing is finished. From man sh
:
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
foo
In the first case, 'foo' was consumed by sh
as an option. In the second, it's correctly interpreted as $1
on the string.
Best Answer
Git supports this command:
Check out the
origin/master
branch and then resetmaster
branch there.