Distributed version control comes with many ways to organize your code. The master branch is by convention the primary focal point for development. This could be a stable or shared hod podge of integration.
In either case I recommend that you delete your local copy of master, leave the remote branch. When you you are wanting to start work fetch remote and checkout origin/master (or whatever your working branch is).
Yes this puts you into a detached head. This isn't an issue, git will let you build your branch any time. And it is much easier to name a branch after you have some work behind it to name it.
How is Local Master Used
Pull requests killed the local master branch. The purpose for this branch is to work out a merge of branches for other work happening. And it is still a valid option picked up by Github.
Pull/Merge requests provide a web interface and will perform clean merges. Merge conflicts are expected to be addressed in the work branch, and one reason rebase is preferred so many places.
I recommend deleting your local master, but if you have a need to control master locally, by all means bring it back. Just remember git will manage origin/master so you don't have to.
Top comments (6)
This seems like a really odd flow. In my mind, you're trying to prevent commits directly on master which is good practice. However, this can easily be achieved by setting the permissions on the repository so that master can only received code via pull/merge requests.
I'm actually trying to eliminate the maintenance of a local master. It also emphasizes keeping up to date with remote when work starts.
I'm trying to avoid poorly named branches, ones that aren't named for the work being done.
If you're already comfortable with remotes and branch management then this advice isn't necessary, but I'd be curious what you do on local master?
I've probably run all of the following on/using master in the last 2 weeks (albeit some via aliases)
Yep most of these would be equal with origin/master, but that is more typing, and others might result in a longer message (merge commit)
Not checking my commands but what is wrong with
Seems odd recommendation, even if someone does not need to commit direct on master, the repository itself as you stated in your first phrase is a DCVS, and by any means you have a "snapshot" from your remote (possibly origin but could be any upstream or fork ...).
A few examples you may consider keep master:
Elliot mentioned about protected branch feature, which is something not "git native" but mostly of providers supports it, you can also check on git hooks to handle things agnostic to providers
If you delete your local master you still have references to the remote master. I don't see how a local master gets around air gaps or network restrictions, your local master can't be updated until git updates the origin/master branch.
Branch origin/master will always reflect the remote master branch after a fetch, even if a force push was done. The only exception to this is if your remote has a Master branch and you're on Windows.