1

For the majority of my scenarios, git flow has done quite well. Given the following scenario (in chronological order), however, I'm not sure what the best way to move forward would be:

  1. Release 1.0 is pushed to production environment (done with "git flow release")
  2. Post-release development of new features and bug fixes are done in development branch
  3. A few major bugs and a couple of missing requirements surface in release 1.0 and client decides they can't wait for next major release, but some of these bugs/features have already been addressed in the development branch, in addition to some work that should wait for the next release.

If we had a crystal ball, I believe we should have applied the updates as hot fixes rather than in the development branch, but it's too late for that now. If we start a hotfix (off the master branch), we could literally copy & paste the appropriate updates between branches (gross), but then we'll end up with some nasty conflicts when we merge the branches (at some point).

In this particular situation, what would be the best way to keep headaches at a minimum?

Improve this question

1 Answer 1

Reset to default
2

Create a hotfix branch, then use 'git cherry-pick' to pull in the specific changes from your dev branch. 

git cherry-pick [commitid]

If you ever do a general merge in the future, the cherry-picked commits will not be duplicated or have conflicts, git is smart enough to work it out.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

That worked perfect for me. I was always under the impression cherry-picked commits would cause conflicts. Thank you for your help!

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.