Answers: <blockquote>
    <p>I read in Git, Cherry picking is bad.</p>
  </blockquote>
  
  <p>Be careful of such blanket statements. They take on a life of their one, and after a while you have a lot of myths in your team (or workplace) about no cherry-picking, no re-basing, no xyz. These are all just tools; there are times to use them, and times to not use them. Nothing is generally bad.</p>
  
  <blockquote>
    <p>Sometimes , we do not move all Release items into Master, many reasons:, delay schedule, conduct more testing, late issues. What is the proper Git Devops strategy to only move certain items into Master?</p>
  </blockquote>
  
  <p>Adam Dymitruk's <a href="http://dymitruk.com/blog/2012/02/05/branch-per-feature/" rel="nofollow noreferrer">Branch per Feature</a> works splendidly for that. In short:</p>
  
  <p>There are these branches:</p>
  
  <ul>
  <li>1 <code>master</code> branch</li>
  <li>1 <code>qa</code> branch</li>
  <li>n <code>feature-123</code> branches</li>
  </ul>
  
  <p>The general principles:</p>
  
  <ul>
  <li><em>Every</em> branch starts at <code>master</code>.</li>
  <li><em>Only</em> <code>feature-123</code> branches receive regular commits.</li>
  <li><code>qa</code> is created by starting fresh from <code>master</code>, and then merging any <code>feature-123</code> branches that should be in testing. Whenever <code>qa</code> needs to be changed, it is created fresh again, there are no other commits into it. This happens very frequently.</li>
  <li>When <code>qa</code> has been released/deployed, it is simply renamed to <code>master</code> and replaces the previous one. At this point, all remaining <code>feature-123</code> branches are rebased onto the new master. The <code>git rerere</code> cache is used to avoid having to do repeated conflict resolution.</li>
  </ul>
  
  <p>This scheme works great <em>if</em> you have developers who can stomach the rebases. You frequently find people who think they are bad, or who simply do not allow it - then you're out of look obviously. But if you get it to run in your team, it is very smooth, and ultra flexible. You literally never ever need to "back a commit out" or do cherry-picking to revert a commit, or whatever.</p>
  
  <p>Read Adam's page, it explains this in more detail, but basically that's about it. You'll need to create your own tooling for the individual steps (for example, to pull the feature branches which are supposed to go into <code>qa</code> from your Jira instead of manually doing that), but that's not too hard.</p>
  
  <p>Addendum:</p>
  
  <ul>
  <li>Trivially, you can have more than one <code>qa</code>-type branch at any point in time. For example, you will likely start with one that always has all features which are deemed close to "done" (but which may not have successfully passed test yet); and maybe another one (let's call it <code>rc</code> - release candidate) which contains a subset of that for the very next release. </li>
  <li>Adam also describes a <code>ci</code> branch; it is nice, but optional (we don't use it at all, and are not missing it).</li>
  </ul>
  
Answers: CC BY-SA 4.0
Answers: 2018-07-10T22:18:33.920Z
Answers: 2018-07-10T22:18:33.920Z
Answers: AnoE
Answers: <p>we had the same problem, so now we have:</p>
  
  <ul>
  <li><p>jira (stories and tasks) </p></li>
  <li><p>bitbucket (git)</p></li>
  <li><p>bamboo (automated builds all branches and before pull-request)</p></li>
  </ul>
  
  <p>brachces:</p>
  
  <ul>
  <li><p>production (only production release any time)</p></li>
  <li><p>master (development but ready to production branch)</p></li>
  <li><p>feature-branches (from master) -> (completed story/task + all tests) -> master</p></li>
  <li><p>hotfix-braches (from production) 
              -> all-branches-> production -> master -> feature-branches</p></li>
  </ul>
  
Answers: CC BY-SA 4.0
Answers: 2018-07-10T18:44:31.477Z
Answers: 2018-07-10T18:44:31.477Z
Answers: speedee
Body: <p>We have main two Git branches at our company:
  During our Sprint,</p>
  
  <p>Everyone has (local branches)</p>
  
  <p>Release branch: Contains prepared/developed code, ready for testing,  and </p>
  
  <p>Master branch: Production- final ready code</p>
  
  <p>I read in Git, Cherry picking is bad.</p>
  
  <p><a href="https://blogs.msdn.microsoft.com/oldnewthing/20180312-00/?p=98215" rel="nofollow noreferrer">https://blogs.msdn.microsoft.com/oldnewthing/20180312-00/?p=98215</a>
  <a href="http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html" rel="nofollow noreferrer">http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html</a></p>
  
  <p>After items are placed in master, they are ready to be deployed.
  Sometimes , we do not move all Release items into Master, many reasons:, delay schedule, conduct more testing, late issues. What is the proper Git Devops strategy to only move certain items into Master? Should we backout commits, so we can do a clean merge?</p>
  
  <p>Databases are different, as we are conducting change scripts, and not overwriting binaries like applications, etc.</p>
  
  <p>Example:</p>
  
  <p>Release branch <em>-------</em> ------------->   Master</p>
  
  <p>Commit A, B, C, D, E   ------------->   Commit B,D     </p>
  
Tags: <git><databases>
Title: Merging Git Database Commits from One Branch to Another without Cherrypicking
UserDisplayName: SkyPool392
ThreadText: # Merging Git Database Commits from One Branch to Another without Cherrypicking
  
  (Asked by: username_0 on 2018-07-09)
  
  We have main two Git branches at our company:
  During our Sprint,
  
  Everyone has (local branches)
  
  Release branch: Contains prepared/developed code, ready for testing, and
  
  Master branch: Production- final ready code
  
  I read in Git, Cherry picking is bad.
  
  <https://blogs.msdn.microsoft.com/oldnewthing/20180312-00/?p=98215>
  <http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html>
  
  After items are placed in master, they are ready to be deployed.
  Sometimes , we do not move all Release items into Master, many reasons:, delay schedule, conduct more testing, late issues. What is the proper Git Devops strategy to only move certain items into Master? Should we backout commits, so we can do a clean merge?
  
  Databases are different, as we are conducting change scripts, and not overwriting binaries like applications, etc.
  
  Example:
  
  Release branch *-------* -------------> Master
  
  Commit A, B, C, D, E -------------> Commit B,D
  
  **Tags:** git, databases
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2018-07-10. Score: 2
  
  > I read in Git, Cherry picking is bad.
  
  Be careful of such blanket statements. They take on a life of their one, and after a while you have a lot of myths in your team (or workplace) about no cherry-picking, no re-basing, no xyz. These are all just tools; there are times to use them, and times to not use them. Nothing is generally bad.
  
  > Sometimes , we do not move all Release items into Master, many reasons:, delay schedule, conduct more testing, late issues. What is the proper Git Devops strategy to only move certain items into Master?
  
  Adam Dymitruk's [Branch per Feature](http://dymitruk.com/blog/2012/02/05/branch-per-feature/) works splendidly for that. In short:
  
  There are these branches:
  
  * 1 `master` branch
  * 1 `qa` branch
  * n `feature-123` branches
  
  The general principles:
  
  * *Every* branch starts at `master`.
  * *Only* `feature-123` branches receive regular commits.
  * `qa` is created by starting fresh from `master`, and then merging any `feature-123` branches that should be in testing. Whenever `qa` needs to be changed, it is created fresh again, there are no other commits into it. This happens very frequently.
  * When `qa` has been released/deployed, it is simply renamed to `master` and replaces the previous one. At this point, all remaining `feature-123` branches are rebased onto the new master. The `git rerere` cache is used to avoid having to do repeated conflict resolution.
  
  This scheme works great *if* you have developers who can stomach the rebases. You frequently find people who think they are bad, or who simply do not allow it - then you're out of look obviously. But if you get it to run in your team, it is very smooth, and ultra flexible. You literally never ever need to "back a commit out" or do cherry-picking to revert a commit, or whatever.
  
  Read Adam's page, it explains this in more detail, but basically that's about it. You'll need to create your own tooling for the individual steps (for example, to pull the feature branches which are supposed to go into `qa` from your Jira instead of manually doing that), but that's not too hard.
  
  Addendum:
  
  * Trivially, you can have more than one `qa`-type branch at any point in time. For example, you will likely start with one that always has all features which are deemed close to "done" (but which may not have successfully passed test yet); and maybe another one (let's call it `rc` - release candidate) which contains a subset of that for the very next release.
  * Adam also describes a `ci` branch; it is nice, but optional (we don't use it at all, and are not missing it).
  
  
  ---
  
  ### Answer by username_2 on 2018-07-10. Score: 0
  
  we had the same problem, so now we have:
  
  * jira (stories and tasks)
  * bitbucket (git)
  * bamboo (automated builds all branches and before pull-request)
  
  brachces:
  
  * production (only production release any time)
  * master (development but ready to production branch)
  * feature-branches (from master) -> (completed story/task + all tests) -> master
  * hotfix-braches (from production)
    -> all-branches-> production -> master -> feature-branches
  
  
  ---
  
  