Last updated October 24, 2013.

Although master branches are commonly used in the Git world, the Drupal community uses major version branches (e.g., 7.x-1.x) instead, since master could be compatible with D6, D7, or even D8.

Especially projects converted from CVS may still have the latest and greatest code in master (the old CVS HEAD branch).

To move from master to 7.x-1.x (or whatever major version it actually is):

  1. Perform the actual change:

    git checkout master
    git checkout -b 7.x-1.x
    git push origin 7.x-1.x
  2. Find the release node pointing at master either on the Project's main page or by Viewing all releases. Click the title:
    title.png
  3. Click the Edit tab:
    release_nodeedit.png
  4. Once on the page, choose the appropriate branch. Note that this field will only be editable if there is an appropriately named branch available that is not already associated with another release node.
    release_node.png

    Save the release node.

  5. Set the appropriate default branch.
  6. Delete the master branch:
    git checkout 7.x-1.x
    git branch -D master
    git push origin :master

    Be sure you've set the appropriate default branch as directed above before you delete master entirely.

Comments

Beware of using git add -A as in step 5 (Clean out the master branch). Luckily for me, I checked git status before committing my code. I had some temporary files from my text editor: .mymodule.module.swp and .mymodule.test.swp. Because they start with ".", they were not removed by rm -R ./*. (Neither was .git/. I need some sleep: at first, I thought it had to do with my .gitignore settings.)

I used git commit -m instead of git commit -am. I think the recommended -am options would have committed my "dot files".

I think that the instructions should end with

git push origin master

I think that the instructions should end with

git push origin master

If you're referring to the optional step 7 last command in step 6, it was describing how to delete the remote branch, and the instructions are correct. Here are multiple guides which highlight the (slightly odd) git push [remotename] :[branch] syntax to delete remote branches:

Yes, I did mean the optional Step 7. Thanks for supplying the reference.

This documentation is not clear enough about when delete the branch master or not.

My point is, there are lots of commits in master branch inherited from most projects migrated from CVS HEAD. So it would be sad to just drop all that source code.

Also, there are new contributors that already know git, they are creating sandbox projects and many of them may consider that using master branch is a good practice. What if they come here and feel forced to create some other branch to store their code somewhere? Where? will they create a 7.x-1.x-unstable branch? or just rename "master" to "cleanup-later" or "drupal-hates-master-branch"?

Guess that we need some NOTICE like: be aware that you might delete portions of your project's commit log permanently, please review the Git branches naming conventions and create the corresponding branch or branches to safely store your valuable source code and then feel free to safely remove master branch.

I'm doing some assumptions in previous paragraph, but hope that the idea is clear.

--
Dear friend, I pray that you may enjoy good health and that all may go well with you, even as your soul is getting along well (3 John 1:2)

If my module is to work for D7, should I do development against 7.x-1.x? What about the -dev branches? When I'm ready to release a stable version, should I create a tag or a branch with 7.x-1.0?

Please see http://drupal.org/node/1015226 for complete documentation about branches and tags as they relate to projects.

FYI the "git branch" help suggests that it should be possible to remove a remote branch, i.e. a branch on the d.o servers, by combining the -r and -d (or -D) options. All that seems to do is remove the local reference to the remote branch, it doesn't actually remove the branch in the remote server. In order to properly remove the remote branch you must use the "git push origin :branchname" command listed above.

--
Damien McKenna | Mediacurrent

The instructions here are in conflict with the current instructions on Drupal.org for creating new sandbox projects. Those instructions tell developers to use "git push origin master" after first initializing the git repository for the project, and they do not provide any instructions to tell developers how to created branches in their sandbox that comply with Drupal's version naming conventions. In effect, therefore, new developers are being instructed to create master branches, while here they are being told to delete them.

----------------
IT consultant, web designer, writer and researcher
http://www.sheldonrampton.com/portfolio

As long as your project is in the sandbox it can stay in the master branch as instructed or suggested by the sandbox version control page.

Before promoting your code from a sandbox to a full project you have to copy the code to a branch and get rid of the code within the master branch. The bottom line is that a full project should not have code inside it's master branch.

Note that in step #1 you are creating a branch using # git checkout 7.x-1.x. Then you are deleting the master branch using "-D" and then you are pushing the changes to the remote Drupal repository so that the master branch gets deleted in the remote as well.

It's true that enforcement of Drupal branching doesn't happen much on sandbox projects (although I had someone file a bug report about this very issue on one of my sandbox projects). However, it seems unnecessarily complicated to tell developers that they should create a "master" branch when starting a sandbox, only to tell them later that they have to delete it.

----------------
IT consultant, web designer, writer and researcher
http://www.sheldonrampton.com/portfolio

If you don't have a valid branch name Drupal.org will not let you create a release. Creating a release is merely filling up a form to tell Drupal what code should be used from your git repository in order to build the downloadable code.

Valid branch names are:

  • 8.x-1.x
  • 7.x-1.x
  • 6.x-2.x

Once you have a Git branch like 7.x-1.x and the branch has been pushed to the Drupal repository you can create a release on Drupal. To create a release look for the link "Add new release" below the description of your project.

Releases for the above branches can be called respectively:

  • 8.x-1.x-dev
  • 7.x-1.x-dev
  • 6.x-2.x-dev

After you have created the release Drupal packaging script will use the code from Git and will create the downloadable files, something like myproject-7.x-1.x-dev.tar.gz.

This took me a while to understand. Unfortunately the process for contributing to Drupal is not very user friendly but it works. Be patient and you will get it.

I am unable to delete master branch.

I have done the steps one

Perform the actual change:
git checkout master
git checkout -b 7.x-1.x
git push origin 7.x-1.x

Currently i have moved my code to 7.x.1.x branch.

I am unable to find step 2. then i go to delete master branch by using the commands
git branch -D master
"Deleted Branch master"
but when i check it. by ventral.org or if i go through to checkout by git clone it clones by master branch by default. i have already changed by default branch t0 7.x-1.x in edit page of my project.

My project link is https://drupal.org/sandbox/it.ravindrasingh/1970736

Ravindra:

The command
git branch -D master
should have deleted the master branch, but only from your local repository. Check with
git branch -a

You still have to follow the next step in the instructions in order to delete d.o's copy of the branch:

git push origin :master

For an explanation, either read git help push or the first three comments on this page (although there is no longer a "Step 7" in the main page).

Of course, pay attention to all the warnings in the main article. Do not delete the master branch until you are sure that the new one has been pushed.

@benjifisher , i have used these commands
in that way for moving into branch first time.

git checkout master
git checkout -b 7.x-1.x
git push origin 7.x-1.x

after that i did.

git checkout 7.x-1.x
git branch -D master
git push origin :master

Output came like
cannot access the url 'sandbox url' error code 22 like.

Till that time i was unable to do this

today first i did
git checkout 7.x-1.x
then manually i have deleted all the file from repository.

then directly i used
git push origin :master

and got successfully deleted master branch and then i had checked in ventral.org. it was perfectly deleted and all the files moves 7.x-1.x branch.

So finally i found my issue was in these lines.

git checkout -b 7.x-1.x
git push origin 7.x-1.x

Completely deleting master (and losing its history) is not really necessary, in my opinion. You can do a variety of things, like simply renaming your master branch to 7.x-x.x, and fix the problem while retaining your history in the process.

git branch -m <oldname> <newname>

Or, if you already have7.x-x.x, you can merge it into master, delete the 7.x-x.x branch, and rename master to 7.x-x.x.

See: http://www.dmo.ca/blog/20080307124544/

Thanks @stickywes i will try git branch -m .

That will take care of your local repo, but you'll still have to delete the remote branches and then push your newly-renamed branch back up. There isn't a convenient command to rename branches on the other repo, just your local copy.

Also, these changes get messy if anyone else has cloned the repo. This is always a problem when you try to re-write history on a remote repo that other people have access to.

Regardless, there are a lot of Drupal projects that never deleted their master, so unless you're being forced to I say leave it there and avoid the headache of trying to clean up messes or losing commit history.

Well, the instructions on this page say explicitly that people should "Delete the master branch." Are you saying that you disagree with the instructions?

----------------
IT consultant, web designer, writer and researcher
http://www.sheldonrampton.com/portfolio

I do, yeah. If a Drupal Project will function just fine with a master branch present in the repo, there is no reason to remove it completely if you've got a decent commit history present. There's another comment here, though, that says they kept the commit history just fine... if so, then I don't see the harm anymore. The article suggests you can lose history if you delete the master branch.

Delete the master branch. [Note: this may delete the prior commit history for commits created on the master branch. It is not technically necessary to delete the master branch. Some projects have committed a single README explaining the situation to 'close off' the master branch.]

I haven't had the experience of losing history when deleting a master branch, and I don't think that's how git works.

My main point is that Drupal.org shouldn't have instructions in one place that tell people to create a master branch when starting a sandbox project, and then telling them later that they should delete the master branch. That just sets up confusion down the road.

----------------
IT consultant, web designer, writer and researcher
http://www.sheldonrampton.com/portfolio

As fas as I can tell, master is unavoidable. You can't "git init" and avoid a master branch from being created automatically at this time. Also; the docs don't explicitly require that master is deleted anywhere, as far as I can tell. If they do, that is just something that has to be adjusted to be more consistent with pages like this one and this one, where they explicitly say it is no longer necessary.

I could see a case where deletion of master would remove history; if you made a commit or two to master that weren't included in your release branches. That wouldn't be a danger if you follow the instructions here, though.

Actually I deleted the master branch following https://drupal.org/empty-git-master#comment-7517673 but I didn't lost the commit history, it just went on the new 7.x-1.x branch.

I had the same experience... I think the line:

"Note: this may delete the prior commit history for commits created on the master branch. It is not technically necessary to delete the master branch. Some projects have committed a single README explaining the situation to 'close off' the master branch."

is confusing for people attempting to get a sandboxed project through review, as there are a lot of people not deleting their master branch due to the possibility of losing commits, where (in my case at least) this did not happen, and as you know a requirement to promote a sandbox to full project is that you do not have a master branch left in Git.

You do not lose commits by deleting the master branch.

----------------
IT consultant, web designer, writer and researcher
http://www.sheldonrampton.com/portfolio

Exactly, hence why I said the line is confusing

Agreed. I deleted the incorrect language from the page.

----------------
IT consultant, web designer, writer and researcher
http://www.sheldonrampton.com/portfolio

Excellent, hopefully that will help with fledgling sandbox projects in the future

Also, @stickywes was incorrect when he wrote previously that you can't use git init to create a git repository without creating a master branch. If you do "git checkout -b" prior to your first commit, the master branch won't get created. For example, you could create a new repository with only a 7.x-1.x branch by doing the following:

git init
git checkout -b 7.x-1.x
git add *
git commit

----------------
IT consultant, web designer, writer and researcher
http://www.sheldonrampton.com/portfolio

You start in an uncommitted master branch. If you want to be unnecessarily nitpicky, I am still correct because you aren't using git init to accomplish what you're doing.

Here's my attempt to delete master branch and the results:

git checkout 7.x-1.x
Switched to branch '7.x-1.x'

git branch
* 7.x-1.x
master

git branch -D master
Deleted branch master (was 6d667d2).

git push origin :master
remote: error: By default, deleting the current branch is denied, because the next
remote: error: 'git clone' won't result in any file checked out, causing confusion.
remote: error:
remote: error: You can set 'receive.denyDeleteCurrent' configuration variable to

remote: error: 'warn' or 'ignore' in the remote repository to allow deleting the

remote: error: current branch, with or without a warning message.
remote: error:
remote: error: To squelch this message, you can set it to 'refuse'.
remote: error: refusing to delete the current branch: refs/heads/master To togbonna@git.drupal.org:sandbox/togbonna/2192407.git
! [remote rejected] master (deletion of the current branch prohibited)
error: failed to push some refs to 'togbonna@git.drupal.org:sandbox/togbonna/2192407.git'

What am I doing wrong?