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
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
And when you want to work on new stuff, just use
git checkout -b my-feature origin/master
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!
Top comments (27)
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.
You could resolve merge conflicts with
origin/masterwithout having amasterup to dateHaving master on my local helps me to fix merge conflict which requires manual intervention.
How would you resolve a merge conflict using origin/master? Seems scary to me. I've always done it manually like @firoz states.
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
Git switch - -detach origin/master
Git merge mybranch
Git commit
Git push origin HEAD:master
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)
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
This article is a good reminder about some aspects of git branching, but the article never states why you should checkout
origin/masterdirectly. Why is checking outorigin/masterbetter than checking out a local copy (master)?I was thinking of the same question!
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)
What is the benefit for "app check"
I do have
masterlocally, 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 toorigin/master(or any other branch i specify, e.g. when iβm sure a PR gets merged really soon).Maybe Iβm being pedantic, but isnβt
origin/masterlocal? We call it a remote reference, but it still exists locally.Yeah, that is completely true.
This is why, keeping a copy from the remote reference
origin/masterup to date is not necessary.This would be why we tend to fork-and-branch (and set branch-protection on the parent project).
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...
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.
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.
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
Feature toggling.
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.
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.
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.
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!
I have the same advice, keep spreading the word.
Delete Your Master
Jesse Phillips γ» Apr 8 γ» 1 min read