DEV Community

loading...
Cover image for Git TIP -  Why you should not keep a local master branch ?

Git TIP - Why you should not keep a local master branch ?

slashgear_ profile image Antoine Caron ・1 min read

When working with git, I have often made the mistake of maintaining a master branch locally updated using these commands.

git checkout master

git pull origin master
Enter fullscreen mode Exit fullscreen mode

I've done this so many times. This allowed me to start a development by being up to date with recent changes.

In fact, it is not necessary to maintain local copies of the branches on which we are not working directly. We already have access to an intact local version of the remote branches.

All this time I could have just done:

git checkout origin/master
Enter fullscreen mode Exit fullscreen mode

And when you want to work on new stuff, just use

git checkout -b my-feature origin/master
Enter fullscreen mode Exit fullscreen mode

Keep in mind that this is valid for master as well as all other branches on which you do not work directly/on which you will commit.

You could also follow my colleague advises.

Let me know if you have any other tricks with Git!

Discussion (29)

pic
Editor guide
Collapse
firozansari profile image
Firoz Ansari

I believe you do need master branch on your local to resolve issues like merge conflict etc. You can create a pre-commit hook which will prevent any commit to master branch. The master branch will then only accept changes through pull requests.

Collapse
slashgear_ profile image
Antoine Caron Author

You could resolve merge conflicts with origin/master without having a master up to date

Collapse
firozansari profile image
Firoz Ansari

Having master on my local helps me to fix merge conflict which requires manual intervention.

Thread Thread
dietertroy profile image
Troy

How would you resolve a merge conflict using origin/master? Seems scary to me. I've always done it manually like @firoz states.

Thread Thread
jessekphillips profile image
Jesse Phillips • Edited

Committing to a detached head is risky because if you change branches you'll need to use reflog to retrieve it. However a branch name can be added at any time

Git branch foo

Collapse
jessekphillips profile image
Jesse Phillips • Edited

Git switch - -detach origin/master

Git merge mybranch

Git commit

Git push origin HEAD:master

Thread Thread
mvz profile image
Matijs van Zuijlen

git checkout master
git pull
git merge mybranch
git push

Seems simpler.

(Actually, for the second step, I use git up, which does pull --rebase=merges --autostash --prune for even more convenience)

Thread Thread
jessekphillips profile image
Jesse Phillips • Edited

Well I would not recommend this flow in general and suggest pull requests. However the main flow for not having master is optimized for is starting working. Instead of

Git switch master
Git pull --ff-only
Git switch -c mybranch

It is

Git fetch
Git switch -c mybranch origin/master

Or

git fetch
git rebase -i origin/master

instead of

git switch master
git pull --ff-only
git switch mybranch
git rebase -i master


And if you must merge on master, but you don't have a local master.

Git fetch
Git switch -c master origin/master

Collapse
madmathmike profile image
MadMathMike

This article is a good reminder about some aspects of git branching, but the article never states why you should checkout origin/master directly. Why is checking out origin/master better than checking out a local copy (master)?

Collapse
anduser96 profile image
Andrei Gatej

I was thinking of the same question!

Collapse
websvc profile image
WEBsvc

One should know at all times on which branch is working on.
And to start with, on an organization a developer should not be able to push into master, it should be a protected branch.
That's why merge/pull requests are for.
Having master locally does not cost space or any thing.
But yeah you can update and resolve conflicts with origin/master, but it gets handy to have master locally for app check once in a while.

I do commit to master in some cases where there's only one branch (ex. project too small)

Collapse
jessekphillips profile image
Jesse Phillips

What is the benefit for "app check"

Collapse
gergelypolonkai profile image
Gergely Polonkai

I do have master locally, and usually use that to track down bugs before i would open a bugfix branch for it. I’m lazy like that :)

Also, i have a neat little script called git-rebase-all. I usually have 50-something branches locally, all unfinished features by me and my colleagues. The script iterates over all my branches and rebase them to origin/master (or any other branch i specify, e.g. when i’m sure a PR gets merged really soon).

Collapse
evolutionxbox profile image
Jonathan Cousins

Maybe I’m being pedantic, but isn’t origin/master local? We call it a remote reference, but it still exists locally.

Collapse
slashgear_ profile image
Antoine Caron Author

Yeah, that is completely true.

This is why, keeping a copy from the remote reference origin/master up to date is not necessary.

Collapse
samuelkupferschmid profile image
Samuel Kupferschmid

Tell this to my colleagues. The whole team works on the master branch... Coming from progressional companies I always feel like the biggest sinner doing it that way...

Collapse
anortef profile image
Adrián Norte

They are working correctly. Branches were made to make people who weren't working together as a team able to collaborate and check each other code before putting it in.

A team of developers that work at the same location in the same codebase daily does not need branches, in fact, they are detrimental because it creates integration overhead and complicated builds.

Collapse
jameslau profile image
James Lau • Edited

As a frontend developer, I'm glad I didn't have to deal with the daily churn of Java code for system wide server level builds. But it is nice to pull a fresh copy from master to my local master to get me started for the day.

I just know that the master works. But we're also notified if the master has errors and are told not to pull.

Collapse
samuelkupferschmid profile image
Samuel Kupferschmid

How would you handle the case when you work on a task which takes let say four days. And it only will only work as a whole thing correctly? Dont push for four days? Give the testers a break for four days? How would you realize code reviews?
I think there is a reason why github and co has pull requests.
Also continuous deployment would be hard because in a team of 3+ people there would always be a incomplete thing in the code base

Thread Thread
anortef profile image
Adrián Norte

Feature toggling.

Collapse
ferricoxide profile image
Thomas H Jones II

This would be why we tend to fork-and-branch (and set branch-protection on the parent project).

Collapse
jameslau profile image
James Lau

When you are working with more than one developer, don't you need an extra copy of master locally in case there are system wide changes? Plus, merge conflicts are dealt with locally and you don't end up hosing the rest of the team.

Collapse
adrinux profile image
Adrian Simmons

Lets take a distributed VCS and make it behave like like a VCS. Lets rely on third party services for workflow...Seriously, go back and read the story of why git came into being.

Collapse
slashgear_ profile image
Antoine Caron Author

That is a great and constructive comment here.

Prove me why using remote reference branch is against the distributed model ?

We tend to use a third party service for the workflow. Yeah ! But this is not the subject here.

The subject here is quite simple. If you don't work on a branch, don't checkout it locally. You already have the related remote reference branch.

Collapse
kimballjohnson profile image
Kimball Johnson • Edited

I appreciate this discussion very much. I've been looking for authoritative answers about this for quite some time. It makes sense to me to keep the merge targets on the repository. Then all you have on your workstation are the changes you've made to code you've fetched into a feature or bugfix local branch.
But not mentioning how the branches on the repository side are arranged makes me wonder whether this discussion is complete and confirmed!
Master is not the only, and probably not the best target for all changes on Origin, is it?
Shouldn't the target for all pull requests be the origin/development branch? And shouldn't master be the merge target for development? And then wouldn't releases be the merge target for master?
How can you explain just a part of this without providing the confirmation by drawing the whole picture?
Thanks for some kind of response!

Collapse
jessekphillips profile image
Collapse
viccw profile image
Vic Seedoubleyew

You can, but I don't think there is any benefit to it, as stated by other comments.

So why make things more complicated than they should? This will just confuse young programmers learning git I think

Collapse
hmartinezdev profile image
Héctor Martínez

Great! I should be doing this. I pushed directly into master by mistake so many times...