My organization does not believe in merge commits. As such, we do work on master and cherry-pick it to typically one stable branch, which I'll name stable here. (We also have a single remote, origin, which simplifies some of the commands here).
So my current flow is as follows:
$ git branch
* master
stable
# do some work and commit it to 'master'
$ git commit -a -m "some message"
# rebase on 'origin/master' because there were commits by colleagues in the meantime
$ git fetch && git rebase origin/master
$ git push origin master
# here's the rub: switch to 'stable', which is present in the local repo and behind 'origin/stable'
$ git checkout stable
# now update (a fetch may be necessary before, depending on how busy the remote repo is), git pull would also do
$ git merge --ff-only
# cherry-pick, push etc.
$ git cherry-pick master ...
My issue is that switching to an existing local branch followed by an update has redundant operations: restoring outdated files. Basically, I'm going to a place just to get to another, when a direct route is possible:
# suppose I have pushed my changes to origin/master already
$ git branch -d stable
# some git grumbling, but origin/stable is ahead, so no commits are lost and the operation has proceeded
$ git checkout stable
Of course, I could make this into an alias. But I'm wondering: is there a better way to switch to a branch and get it updated to its state on the remote? It's also possible I'm overlooking a possible problem with my proposal.
What you are doing now is fine, but if you want to force your stable to match your origin/stable and get onto your stable at the same time, use git checkout or git switch with the -B or -C option respectively, and both names. That is:
git fetch # if needed
git checkout -B stable origin/stable
This is a little dangerous because it does not verify that origin/stable is strictly ahead of stable, i.e., that this branch resetting process will result in a fast forward. To make sure that it will be a fast forward, while you're not on it, you can use the rather obscure sequence:
git push . origin/stable:stable
or the equivalent:
git fetch . origin/stable:stable
You can combine the latter with a git fetch to the remote via:
git fetch origin stable:stable
If the adjustment to your stable is not a fast forward, you'll get a rejection-due-to-non-fast-forward error.
(None of these work when the current branch is named stable; in that case, use git merge --ff-only origin/stable to move forward, or get an error.)
(I would recommend writing a little script to do what you'd like done, and make it handle all the various corner cases, such as inspecting your current branch name.)
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