Reputation: 3086
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?
Upvotes: 2
Views: 1781
Reputation: 9598
I like this workflow which uses a combination of reset --hard
and rebase
:
git checkout master
git fetch --all
git reset --hard origin/master
git checkout feature
git rebase master
Upvotes: 1
Reputation: 61114
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
Upvotes: 3