title: git flow vs cherry-picks
body: <p>We have branches <strong><code>prod</code></strong> for production releases and <strong><code>dev</code></strong> for ongoing development.</p>
  <h2>Our current flow:</h2>
  <p>We work mainly in <strong><code>dev</code></strong> branch and from time to time, customer decides which features/bugfixes he wants to come to <strong><code>prod</code></strong> and we cherry-pick them.</p>
  <p>From my understanding, cherry-picks contradict to <strong><code>git flow</code></strong> model.</p>
  <p>And so far I don't see how to adapt our flow to avoid it.<br />
  <strong><code>git flow</code></strong> assumes that you know beforehand should the change go to <strong><code>prod</code></strong> or not</p>
  <p>Does community see any way around it?</p>
  <h1>UPDATE: I found that my question requires a better clarification of terms</h1>
  <h2>What we use now</h2>
  <h3>To implement a issue #12345</h3>
  <pre><code>git fetch
  git checkout origin/dev -B issue-12345 # new branch for issue #12345 from bug tracking system
  # ... do many atomic commits
  git fetch
  git checkout origin/dev -B dev
  git merge issue-12345 --no-ff -m &quot;Bug #12345 - Bug title from bug tracking system&quot;
  # ... fix merge conflicts if any and commit
  git branch -D issue-12345
  git push
  </code></pre>
  NOTES
  <ol>
  <li>We use atomic commits for each commit to have a clear intent. This simplifies review/blame/bisect processes</li>
  <li>We use custom message for merge as it is way more descriptive than default <code>Merge 'issue-12345' into 'dev'</code></li>
  <li>We force non-fast-forward merges via <code>--no-ff</code> because we want all issue to be represented as a merge. So <code>git log dev --first-parent</code> returns high-level view of the tasks completed</li>
  <li>We don't use <code>git merge --squash</code> and its rebase analogues. We want whole task history to be preserved</li>
  </ol>
  <h3>When client decides that he wants to get issue #12345 into production</h3>
  <pre><code>git fetch
  git checkout origin/prod -B issue-12345
  git log origin/dev --grep &quot;#12345&quot; --oneline --reverse # get all commits that have to be cherry-picked, usually that's only one merge commit (abcd1234)
  git cherry-pick abcd1234 -x -m 1 # '-m 1' required for cherry-picking merge commit
  # ... fix merge conflicts if any and commit
  # ... repeat for other commit if any
  git checkout origin/prod -B prod
  git merge issue-12345-prod --no-ff -m &quot;Bug #12345 - Bug title from bug tracking system&quot;
  # ... fix merge conflicts if any and commit (although that's unlikely for them to occur)
  git branch -D issue-12345
  git push
  </code></pre>
  <h2>What <code>git flow</code> told us to do</h2>
  <p>See <a href="http://nvie.com/posts/a-successful-git-branching-model/" rel="nofollow noreferrer">http://nvie.com/posts/a-successful-git-branching-model/</a> for more details</p>
  <p>In terms of that article our <code>dev</code> branch corresponds to <code>develop</code>, <code>prod</code> corresponds to <code>master</code>, release branches are not used</p>
  <p>According to <code>git flow</code>, only feature branches should be based on <code>dev</code> branch, and they are never merged to <code>prod</code>.</p>
  <p>However hotfix branches should be based on <code>prod</code> and then merged to both <code>prod</code> and <code>dev</code>.</p>
  <h2>Why <code>git flow</code> is not applicable for us</h2>
  <ol>
  <li>We don't know beforehand if the task will need to go to <code>prod</code> branch or not.</li>
  <li>If we base feature branch from <code>dev</code>, we won't be able to merge it to <code>prod</code> later on if that will be requested (possibly much-much later)</li>
  <li>If we base feature branch from <code>prod</code>, we won't be able to benefit from other tasks completed before.</li>
  </ol>
  <h3>Example 1</h3>
  <p>Let's say we have a task #12345 to implement a new <code>Contact Us</code> page. And then we have a task #23456 to change the page's background color from white to yellow.</p>
  <p>We based our <code>issue-12345</code> branch from <code>prod</code> and then merged it into <code>dev</code> and waiting for approval to merge it into <code>prod</code>.</p>
  <p>Then we start working on <code>issue-23456</code> and based on <code>prod</code> again. But <code>prod</code> code doesn't even have any mentions of <code>Contact Us</code> page yet. So we'll have to do some quirks such as merging <code>issue-12345</code> branch into <code>issue-23456</code> first.</p>
  <p>That's complicated enough for even that simple case. And you can imagine it will be much more difficult if you want to use some code introduced in other task.</p>
  <h3>Example 2</h3>
  <p>Task #34567 asks to implement <code>Feedback</code> page. This page is very similar to <code>Contact Us</code> page so it has similar css. We would like to reuse it. But how? It's not fair to say that #34567 depends on #12345. So it would be illogical to base <code>issue-34567</code> on <code>issue-12345</code>. So what? Rewrite code manually? Copy-paste? Or still cherry-picks?</p>
  <p>I don't see any reasonable solution for such issue.</p>