Question

Recently we have been finding ourselves in situations where we want to merge our test branch with production and exclude specific commits. There have been two ways I have been going about it, one is to merge test with production and do a rebase against the merge commit (git rebase -i HEAD~1) and remove the commits that I do not want. Another would be to cherry pick the commits that we want. I am trying to avoid cherry picking all together since it seems to create a new commit on the separate branches and dirty up the working trees.

Is rebasing the merge commit a good strategy? Does anyone see anything wrong with this?

Thanks in advance.

Was it helpful?

Solution

I'd recommend adopting git flow, rather than wrangling with complicated rebases and merges for deployment. It supports the notion of mainline development, releases, hotfixes, and feature branches. Following that model, you'd only deploy your release and hotfixes branches.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top