0

We are merging feature-branch -> release-branch.

We accidentally pushed a commit to release-branch instead of feature-branch.

How can we move the commit over to feature-branch and out of release-branch while at the same time allowing us to continually make changes to feature-branch and eventually merge it all properly down to release-branch?

We could do:

git checkout feature-branch
git merge release-branch
git checkout release-branch
git reset --hard HEAD~1

But how can you make changes to feature-branch and then do a merge down to release-branch which pulls down the original commit and changes into release-branch?

Can you do this?

git checkout feature-branch
//Make changes to feature-branch
git checkout release-branch
git merge feature-branch
Marcus Leon
  • 55,199
  • 118
  • 297
  • 429
  • You should protect your release branch from direct pushes. Each git hosting provider I know can set these branch policies. – rubenvb Apr 08 '16 at 22:10
  • noted :) Next time.... – Marcus Leon Apr 09 '16 at 12:10
  • Possible duplicate of [Move the most recent commit(s) to a new branch with Git](http://stackoverflow.com/questions/1628563/move-the-most-recent-commits-to-a-new-branch-with-git) – Marcus Leon Apr 09 '16 at 13:02

2 Answers2

4

Sure you can do that, but since you said you "pushed" the commit, it seems not only your local repository is affected. So after the git reset --hard HEAD~1 you have to do a git push --force to push the non-forward update to the remote release branch.

Similarly all developers who pulled the wrong commit of the release-branch already into their local repository have to do a git reset --merge origin/release-branch to get it set to the new remote state (whereas origin has to be replaced with the name of the remote).

David Ongaro
  • 3,568
  • 1
  • 24
  • 36
  • There's no `--force` on `git pull`, but those who did pick up the commit that the OP wants to discard, *do* have to take action on their end to discard it, typically a reset or rebase. (They should look at the "recovering from an upstream rebase" section of their git documentation.) – torek Apr 09 '16 at 03:36
  • @torek I don't think anyone else has picked up the commit. But if they have what actions do they need to take? How does their branch look once they sync to remote after the `push --force`? – Marcus Leon Apr 09 '16 at 12:08
  • @david what happens if after all this we eventually merge feature-branch into release-branch? Will that merge work and include the changes that were once reset in release-branch? – Marcus Leon Apr 09 '16 at 12:09
  • @torek: If I type `git help pull` there's a documented `f, --force` option for the fetch part of git pull. – David Ongaro Apr 09 '16 at 15:17
  • @MarcusLeon: From the point of view of the release-branch the commit never happened after the `reset --hard`, so the merge works like every other merge. (Btw. avoid the `--hard` option, the `--merge` option is safer in that it doesn't lose uncommited changes in your working directory). Only when you do a revert instead of a reset you have to mind to revert the revert before the merge (see my comment to @JimFlood) – David Ongaro Apr 09 '16 at 15:21
  • 1
    @DavidOngaro: Ah, I stand corrected, pull indeed passes the option through to fetch. However, the force option is generally only needed if you use the `:` syntax, e.g., `git fetch master:master` for instance, or `git pull release:release`. Normally you would not use this even with `git fetch`, much less with `git pull`; usually one should just let the `remote..fetch` line specify that the local-side updates go to `refs/remotes//` (with automatic forcing). – torek Apr 09 '16 at 22:32
  • @torek: you're right, using `git pull` is not a good option as this implies a merge, but we want to keep the same history as we have on the remote. Therefore we need to do a `reset` here. I'll correct my answer accordingly – David Ongaro Apr 19 '16 at 05:54
0

If you want to keep things simple, just cherry pick the commit from release-branch over to feature-branch, then just revert the commit in release-branch. You are not doing anything fancy to history -- just plain vanilla git commands.

Jim Flood
  • 8,144
  • 3
  • 36
  • 48
  • In this case you have to revert the revert when merging the feature-branch back to the release-branch. If possible I find the reset the easier and cleaner solution. – David Ongaro Apr 09 '16 at 15:14
  • @David Ongaro Yes, your answer is better. The first thing I would try is a hard reset to a specific commit. I answered quickly. – Jim Flood Apr 09 '16 at 20:43