3

I have a master branch and a dev branch. e.g.

master: A--B--C

dev: A--B--C--D--E

then I want to release D and E, so I create a release-1.0 branch from master, squash merge dev to release-1.0, so

release-1.0: A--B--C--F(D&E)

after I release, I merge release-1.0 to master.

master: A--B--C--F(D&E)

then I continue my new changes on dev

dev: A--B--C--D--E--G--H

and conflicts happens when I create release-2.0 from master and merge dev to it.

That's the problem I encountered. I realize this is not the right way to use merge squash, I do some search and didn't find a good solution.

Penny Liu
  • 15,447
  • 5
  • 79
  • 98
yukuan
  • 521
  • 5
  • 18

1 Answers1

3

I'd recommend only using regular merges between dev and master. If you really want to squash, you can create a feature branch for it, then squash it into dev once it's done.

Regarding the situation at hand, you can rebase dev commits G and H onto master like this:

git checkout dev
git rebase --onto master <E commit hash>

This is what you'll end up with:

* dbd43d8 (HEAD -> dev) H
* c203a3d G
* 39a258a (master) F(D&E)
* 538454c C
* 8aa2e42 B
* 2f3facb A

Then you can simply fast-forwar merge the master branch.

WofWca
  • 571
  • 3
  • 11
  • Yeah, I understand this is the right way to use merge squash. what if I do really need to do a squash merge from dev to master, I'm thinking is there a better way to handle it instead of resolving the conflict. – yukuan Mar 12 '19 at 04:37