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?
git show-branch *master will show you the commits in all of the branches whose names end in 'master' (eg master and origin/master).
Merge the changes from origin/master into your local master branch. This brings your master branch in sync with the remote repository, without losing your local changes. If your local branch didn't have any unique commits, Git will instead perform a "fast-forward".
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
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With