Why do I need a local master branch?

Question

Our team is using git for quite some time, but still this thing escapes me. I'm constantly getting conflicts with my files that have been merged earlier, and vacuous diffs with the files modified by other team members. Usually, it happens in my branch merged earlier, and it is quite laborious to resolve these issues to get clean mergereq...

Therefore, I'm trying to simplify the development process as much as possible, to have it nuisance-error-resilient as SVN. Can I have one local branch sourced from origin/master which I merge every week? What do I need to do to keep it not stale, is egit pull just enough? Or do I have to dance through

git checkout master
git pull
git checkout my_branch
git merge master

every time? The first command obviously creates local master, which answers my question in the title, but why egit pull wouldn't be just enough?

Answer 1

Git doesn't know that commits have been made to master at origin unless you update the local repo somehow--usually either with a fetch or pull . This means that if you just merge your local copy of master you may be merging an obsolete head state, which can cause problems when you try to push.

You don't need a local master branch. You can avoid that hassle by merging the remote branch:

git merge origin/master

Answer 2

I like this workflow which uses a combination of reset --hard and rebase :

1. Hard override local master with remote origin/master

git checkout master
git fetch --all
git reset --hard origin/master

2. Rebase current development branch to master. Note: Use rebase to avoid 'merge commits'.

git checkout feature
git rebase master

3. And yes, I do this all the time. Technically one could rebase directly to the origin/master, but I like to keep things in sync as much as possible.