How to work on dev branch but keep master as default clone branch

I have a local repository I use to develop some feature. I would like to share that feature while also continuing development on it. For that I want to have a development branch.

I want to allow people to clone my local repo and receive the master branch by default, instead of having to explicitly ask for it, while I have the repo checked out to the development branch.

i.e. allow people to "git clone /sapir/repo/.git" and receive the master branch even though /sapir/repo is actually checked out on the development branch at that moment.

is there a way to achieve this without keeping a second copy of the repository for myself?

Solution

The short answer is no. But you've set up an odd situation:

You have naive users, who are not aware that when they run git clone, they are choosing which branch to have their Git create.¹ Without an explicit choice, they are choosing to have their Git create the branch that your Git recommends.
You are (or are trying to be, at least) a sophisticated user who is aware of how git clone works and hence the fact that, if the person running git clone uses neither -n (to avoid creating a branch at all) nor -b (to choose what to create), the person running git clone will pick up a recommendation from your own Git. Your own Git recommends whichever branch is the current branch in your work-tree, or, if this Git repository is bare, the one that would be current: that is, whatever name is stored in HEAD.

As a sophisticated user, though, you should already know that Git:

can use hard links locally, or use --reference and the alternates mechanism to share object storage;
should have a bare repository to receive git push directives;
and therefore, has no need to have any active work-tree, so that you can store anything you like in the HEAD of this bare repository.

Being aware of these things, you would just make a bare repository, then clone it locally and/or using --reference and work in the clone and not ask this question in the first place. 😀 If you have some special and complicated reason not to use a bare repository, you can also use git worktree add, provided your Git version is at least 2.5 (preferably at least 2.15 to avoid some tricky bugs in git worktree).

¹Remember that git clone copies all commits,² but no branches. Having copied the commits, the last step of git clone—unless inhibited via -n—is to run a git checkout, and that creates a new branch. The fact that this new branch generally has the same name as a branch name in the source of the clone is interesting and useful, but not particularly important since the new clone is a separate repository and thus does not need to use the same names.

²More precisely, it copies all commits that are reachable from all the names that will wind up in the new clone: remote-tracking names and tag names, mostly. With various options, such as --single-branch and/or --no-tags, you can choose which of these names will appear in the clone. You can also create a shallow clone with --depth or --shallow-since and similar options, to exclude some commits and related objects. Quite recently, you can enable promissory packs and thereby create a partial clone, though this needs a lot of work to make it practical for more users.