CODEWITHSUNDEEP
gitversion-control
TAR86
TAR86

Reputation: 164

git switch branch and pull

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.

Upvotes: 3

Views: 9210

Answers (2)

Chuck Lu
Chuck Lu

Reputation: 191

Get all changes first, including remote master branch and stable branch
git fetch --all

Then you can quickly reset local stable branch by the following command
git branch -f stable origin/stable

You can do the cherry-pick after switching the branch
git switch stable

From my experience, the flow you used is weird. Since you use cherry-pick to sync commits to stable branch(it will generate new commits on target branch, although they have same content), what's the meaning of the rebase operation on master and origin/master? It's not recommended to use cherry-pick on long-term branch.

Upvotes: 0

torek
torek

Reputation: 490128

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.)

Upvotes: 4

Related Questions