DEV Community

Jesse Phillips
Jesse Phillips

Posted on

Delete Your Master

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)

Collapse
 
denolfe profile image
Elliot DeNolf

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.

Collapse
 
jessekphillips profile image
Jesse Phillips

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?

Collapse
 
shhac profile image
Paul Somers

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)

git pull --ff-only
git branch --merged
git branch -r --merged
git rebase master
git merge master
git checkout -b
git reset --hard HEAD
git checkout master -- ./foo
git diff master...HEAD -- ./foo

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)

Thread Thread
 
jessekphillips profile image
Jesse Phillips • Edited

Not checking my commands but what is wrong with

git fetch & git switch --detach origin/master
git branch --merged
git branch -r --merged
git rebase origin/master 
git merge origin/master
git switch -c 
git reset --hard HEAD
git checkout origin/master -- ./foo
git diff origin/master...HEAD -- ./foo
Enter fullscreen mode Exit fullscreen mode
Collapse
 
gonzalesraul profile image
Raul Gonzales

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:

  • The same repository could be simply pushed for another remote servers without any connection with origin
  • You still can check on master even when offline or behind a network restriction
  • Can share your repo among process/tools that understand git in air-gaped environment (let's say test a ci pipeline without connections)
  • There is no real effort to keep your branch in-sync with your remote

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

Collapse
 
jessekphillips profile image
Jesse Phillips

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.