title: How do you version control and manage multiple branches of a Database?
body: <p>WARNING: LONG QUESTION.</p>
  
  <p><strong><em>[QUESTION]</em></strong></p>
  
  <p>If the strategy is to have a branch per database, as described in the problem below, where scripts are version controlled.</p>
  
  <p><strong>How do you manage the data migration issues when trying to consolidate to fewer branches?</strong><br>
  <strong>Is it just a cost you incur as part of data migration?</strong></p>
  
  <p>Essentially transform scripts will have to be created at the time of migration.</p>
  
  <p><strong>Is there a better way?</strong><br>
  <strong>Can we have both issues resolved at the same time?</strong><br>
  <strong>What is the best practice?</strong>  </p>
  
  <p><strong><em>[BACKGROUND]</em></strong></p>
  
  <p>At my work place we have a product which has 3 branches. Mainline having the "LATEST AND GREATEST" changes which is not necessary ready for release.</p>
  
  <ul>
  <li>Version B (names have been changed to protect the guilty)</li>
  <li>Version A (names have been changed to protect the guilty)</li>
  <li>Mainline</li>
  </ul>
  
  <p>Because of these branches there is effectively 3 versions of the database.
  Code version control is fairly easy however database version control seems difficult.</p>
  
  <p>Having read <a href="https://stackoverflow.com/questions/115369/do-you-source-control-your-databases">Do you use source control for your database items?</a>
  it seems the best way is to export all the create scripts for each object/table.
  NOTE: How you manage it, in one big script or multiple scripts or a hybrid, is your preference according to the article.</p>
  
  <p>I agree with this and have inquired as to why it's not done.</p>
  
  <p>Currently the DBAs refuse to branch the scripts into branches.
  Aside from laziness as an excuse the reason is to save time with data migration.
  Effectively the database changes are forcibly maintained across all versions.</p>
  
  <p>All the scripts are version controlled and maintain only in mainline.
  Version A and Version B have their own special file that states which change scripts to run on their respective branch. The problem arises when there is a change script, for instance applied to Version A but Version B only requires part of the changes. It is up to the developer to inform the DBAs to update the file which indicates which patches to apply for each branch. For change scripts which does too much manual intervention is needed to manually apply part of the change script.</p>
  
  <p>To update a database on Version A all patches are extracted with Version A's which patch to apply file.</p>
  
  <p><strong><em>[SCENARIO]</em></strong></p>
  
  <ul>
  <li>The 3 versions above exist.</li>
  <li>Database changes occur to Version A.</li>
  <li>Branch consolidation where the code is merged from Version B to A so that Version B can be removed.</li>
  <li>The same needs to happen with the database.</li>
  </ul>
  
  <p>Hope this makes sense.</p>