Keeping a branch up to date with master
I have a remote repository that I've pulled and am branching from. I want to keep the new branch up to date with changes done to master. I'm thinking about the workflow below, does it make sense or are there are better ways to do this?
Initial branching and checkout:
git checkout master
git pull
git checkout -b my_branch
Do some work in my_branch , then periodically:
git checkout master
git pull
git checkout my_branch
git merge master --no-ff
Repeat step 2 as needed, with periodic pushes to the remote my_branch .
Then when ready for a merge back:
git checkout master
git merge my_branch --no-ff
Sound ok?
You can simplify your commands:
1.
git fetch
git checkout -b my_branch origin/master
2.
git fetch
git merge origin/master
git fetch updates your remote branches, there usually is no need to have a local copy of a branch when your are not planning to work on this branch.
You can omit the --no-ff after setting git config --global merge.ff false .
git help config says:
merge.ff
By default, Git does not create an extra merge commit when merging
a commit that is a descendant of the current commit. Instead, the
tip of the current branch is fast-forwarded. When set to false,
this variable tells Git to create an extra merge commit in such a
case (equivalent to giving the --no-ff option from the command
line). When set to only, only such fast-forward merges are allowed
(equivalent to giving the --ff-only option from the command line).
Be aware that git pull is just a combination of git fetch and git merge .
Usually you just want git pull --rebase which is essentially git fetch plus git rebase , and creates a much cleaner history.
Is there any reason for your "periodic pushes"? If no one else is working on the same branch it would be perfectly fine, just to push after finishing everything.
I would advise to use a rebase workflow. So instead of using git pull you should use git pull --rebase .
I would do the same with the feature branch. So instead of doing a git merge master --no-ff I would use a git rebase master . However, if the feature branch is meant to be shared with co-workers during development, then you are better off to merge the master branch periodically into the feature branch.
But to be honest, I work on a small team and if we need to work on a feature branch together and we need to get it up to date with master then we just suspend our work for a short moment (and communicate the process clearly), rebase on master and force push the feature branch. But yep, that doesn't scale for bigger teams. However, I find it much more convenient to work with a feature branch that is rebased on master instead of having to deal with merges from master.
Make sure to read this.
Git workflow and rebase vs merge questions
链接地址: http://www.djcxy.com/p/48948.html下一篇: 让分支与主人保持同步