title: Git strategy to backport bugfixes into older branches (cherry-pick vs. merge)
body: <p>We work as follows in our team:</p>
  
  <ul>
  <li>we have only a <code>master</code> branch in our GitHub repo, it's not stable - thinks get pushed there each day; for stable releases we use tags (for development, we use private forks on GitHub)</li>
  <li>we release a new minor version every 3 weeks, which contains bugfixes and new features (say 1.2.4, 1.2.5, 1.2.6...)</li>
  <li>we also have to maintain each minor old version for a limited amount of time (few months), so when someone uses 1.2.4 while the newest version is 1.2.7, and they find a bug, they can request us to fix the bug on the branch they use. Then we release a <em>patch version</em>, 1.2.4A.</li>
  <li>patches are rather exceptional. We usually do no more than 1-2 patches for the minor release. For most of the releases we don't do patches.</li>
  </ul>
  
  <p><strong>The question is, what's the best strategy to fix the bug on master and the old branch at the same time?</strong></p>
  
  <p>I can think of the two main strategies:</p>
  
  <ol>
  <li><p>Fix the bug on <code>master</code>, then checkout <code>v1.2.4</code>, then <strong>cherry-pick</strong> the appropriate commit (suppose the bugfix is one commit which always holds) and tag the resulting commit as <code>v1.2.4A</code>.</p></li>
  <li><p>Checkout <code>v1.2.4</code>, fix the bug and commit, tag the commit as <code>v1.2.4A</code>, and to incorporate it to <code>master</code>, do a <strong>merge</strong>.</p></li>
  </ol>
  
  <p>I'm rather in favor of the first version (cherry-picking), but I would like to hear the other's comments about pros and cons.</p>
  
  <p><strong>Of course, things can get complicated when the commits in the middle introduce some major changes that can result in the fact that one can't create a commit which will work in both 1.2.4 and in master</strong> (for instance when some function name changed or more complicated things). But the more common situation is that the fix can be ported without problems.</p>
  
  <p>Advantages of cherry-picking from master:</p>
  
  <ul>
  <li><p>I think the history is more "eatable" with cherry-picking. Consider this:</p>
  
  <pre><code>| &lt;- bugfix done on master
  |
  |
  | &lt;- v1.2.7
  ...
  |
  |
  |
  |
  |
  |
  |
  |
  |
  |  - &lt;- v.1.2.4A (cherry-picked from master)
  | / 
  | &lt;- v1.2.4
  </code></pre>
  
  <p>vs this:</p>
  
  <pre><code>| &lt;- bugfix merged to master
  |\ 
  | \
  |  |
  |  |   &lt;- v1.2.7
  ...
  |  |
  |  |
  |  |
  |  |
  |  |
  |  |
  |  |
  |  |
  |  |
  |  - &lt;- v.1.2.4A (direct bugfix)
  | / 
  | &lt;- v1.2.4
  </code></pre>
  
  <p>Think of having dozens of commits in between. Consider having multiple patches applied like this in parallel. Half of the screen will be polluted.</p></li>
  <li><p>Let's say I fixed an issue on <code>v1.2.4</code>, but in a few days someone asks me for a patch on <code>v1.2.3</code>. Cherry-pick is the most sensible way to do it.</p></li>
  </ul>
  
  <p>Are there any advantages of merging in our case that I overlooked? I can understand it preserves the connection between the two commits better than cherry-picking, but we keep a documentation of releases and all of this is also tracked there. </p>