window.pipedriveLeadboosterConfig = { base: 'leadbooster-chat.pipedrive.com', companyId: 11580370, playbookUuid: '22236db1-6d50-40c4-b48f-8b11262155be', version: 2, } ;(function () { var w = window if (w.LeadBooster) { console.warn('LeadBooster already exists') } else { w.LeadBooster = { q: [], on: function (n, h) { this.q.push({ t: 'o', n: n, h: h }) }, trigger: function (n) { this.q.push({ t: 't', n: n }) }, } } })() Managing Database Structure Across Multiple Branches - The Codest
The Codest
  • About us
  • Services
    • Software Development
      • Frontend Development
      • Backend Development
    • Staff Augmentation
      • Frontend Developers
      • Backend Developers
      • Data Engineers
      • Cloud Engineers
      • QA Engineers
      • Other
    • It Advisory
      • Audit & Consulting
  • Industries
    • Fintech & Banking
    • E-commerce
    • Adtech
    • Healthtech
    • Manufacturing
    • Logistics
    • Automotive
    • IOT
  • Value for
    • CEO
    • CTO
    • Delivery Manager
  • Our team
  • Case Studies
  • Know How
    • Blog
    • Meetups
    • Webinars
    • Resources
Careers Get in touch
  • About us
  • Services
    • Software Development
      • Frontend Development
      • Backend Development
    • Staff Augmentation
      • Frontend Developers
      • Backend Developers
      • Data Engineers
      • Cloud Engineers
      • QA Engineers
      • Other
    • It Advisory
      • Audit & Consulting
  • Value for
    • CEO
    • CTO
    • Delivery Manager
  • Our team
  • Case Studies
  • Know How
    • Blog
    • Meetups
    • Webinars
    • Resources
Careers Get in touch
Back arrow GO BACK
2016-07-09
Software Development

Managing Database Structure Across Multiple Branches

Tomasz Kowalewski

Developing an app does not only mean implementing new functions or patching it. Sometimes you have to reverse the changes and go back to the previous stage of a project. A frequent issue that can come up while working on multiple branches is connected to maintaining the appropriate version of a database structure. Programmers, who use rails, have ready-made solutions at their disposal. These solutions support the implementation and control of database changes – these are migrations. I will not describe how it works and what possibilities it brings – I would like to focus on the problem of maintaining the appropriate version of a database structure while switching branches.

The database layer of an app is a separate being and is controlled only by migrations. While creating new migrations, remember to make the planned transformation of a database structure reversible. Of course, in extreme cases, we can raise IrreversibleMigration in the down method. This will also inform us about the fact that the migration cannot be reversed. There are different types of changes that we make in the migration – creating, modifying and removing tables, columns or indexes. Deleting and modifying operations are the most sensitive to change. Why? Let’s consider the following scenario:We are working with the master branch, which is our main working path. Currently we have one table:

 class CreateArticles < ActiveRecord::Migration
   def change
     create_table :articles do |t|
       t.string :name
       t.text :description
       t.string :status, null: false
       t.timestamps null: false
     end
   end
 end

Our Article model has such validations which require the presence of name, description and status attributes.

 class Article < ActiveRecord::Base
   validates :name, presence: true
   validates :description, presence: true
   validates :status, presence: true
 end

We are implementing changes into our articles table on feature development branch and we delete the status column.

 class RemoveStatusColumnFromArticles < ActiveRecord::Migration
   def change
     remove_column :articles, :status, :string
   end
 end

We execute the migration:

 $ [example/feature]: bundle exec rake db:migrate
 == 20150605120955 RemoveStatusColumnFromArticles: migrating ===================
 -- remove_column(:articles, :status, :string)
   -> 0.0717s
 == 20150605120955 RemoveStatusColumnFromArticles: migrated (0.0718s) ==========

The schema for a database changes:

diff --git a/db/schema.rb b/db/schema.rb
index 2a100a9..76438c1 100644 --- a/db/schema.rb +++ b/db/schema.rb @@ -11,14 +11,13 @@ #

It's strongly recommended that you check this file into your version control system.

-ActiveRecord::Schema.define(version: 20150605120350) do
+ActiveRecord::Schema.define(version: 20150605120955) do
  createtable "articles", force: :cascade do |t|
    t.string   "name"
    t.text     "description"
-    t.string   "status",      null: false     t.datetime "createdat",  null: false
    t.datetime "updated_at",  null: false
  end

end

Next, we commit the changes to the feature branch. To simulate this issue we switch the current branch to master. The base structure was changed by migration, which deletes the status column on the feature branch. Let’s try to use the following command:

Article.create!(name: "Kaboom", description: "Lorem ipsum...", status: "active")

What will happen after executing the above mentioned code? The error: ActiveRecord::UnknownAttributeError: unknown attribute 'status' for Article will be raised and that’s because of the incompatible structure version of a database. Before changing the branch to master we should roll back the a migration that deletes the status column from the Article table.

What can we do in order to check if we have to roll back some migrations before switching the branches? With the use of the version control system (here it is git) we can check our work by creating a helpful alias:

 ~/.gitconfig
 [alias]
  migrations = "!f() { git diff --name-only $1..$2 db/migrate | tr -d '[A-Za-z/_.]'; }; f"

Executing the git migrations master feature command will result in the list of migration versions, which are located on feature branches, and which cannot be found on master.

 $ [example/feature]: git migrations master feature
 20150605120955

Thanks to this information we can easily roll back the changes done in the database structure before switching to master.

 $ [example/feature]: bundle exec rake db:migrate:down VERSION=20150605120955
 == 20150605120955 RemoveStatusColumnFromArticles: reverting ===================
 -- add_column(:articles, :status, :string)
   -> 0.0009s
 == 20150605120955 RemoveStatusColumnFromArticles: reverted (0.0045s) ==========

One more thing that we should do after rolling back the migration is to restore the status of a database schema.

$ [example/feature]: git status
On branch feature
Changes not staged for commit:
 (use "git add ..." to update what will be committed)
 (use "git checkout -- ..." to discard changes in working directory)

modified:   db/schema.rb

no changes added to commit (use "git add" and/or "git commit -a")
$ [example/feature]: git checkout db/schema.rb
$ [example/feature]: git status
On branch feature
nothing to commit, working directory clean

Now we can easily switch to the master branch.

The given example is not a complicated problem to solve but it should help you realize how important it is to maintain the structure of a database during the change in the work context.

Related articles

Software Development

Build Future-Proof Web Apps: Insights from The Codest’s Expert Team

Discover how The Codest excels in creating scalable, interactive web applications with cutting-edge technologies, delivering seamless user experiences across all platforms. Learn how our expertise drives digital transformation and business...

THECODEST
Software Development

Top 10 Latvia-Based Software Development Companies

Learn about Latvia's top software development companies and their innovative solutions in our latest article. Discover how these tech leaders can help elevate your business.

thecodest
Enterprise & Scaleups Solutions

Java Software Development Essentials: A Guide to Outsourcing Successfully

Explore this essential guide on successfully outsourcing Java software development to enhance efficiency, access expertise, and drive project success with The Codest.

thecodest
Software Development

The Ultimate Guide to Outsourcing in Poland

The surge in outsourcing in Poland is driven by economic, educational, and technological advancements, fostering IT growth and a business-friendly climate.

TheCodest
Enterprise & Scaleups Solutions

The Complete Guide to IT Audit Tools and Techniques

IT audits ensure secure, efficient, and compliant systems. Learn more about their importance by reading the full article.

The Codest
Jakub Jakubowicz CTO & Co-Founder

Subscribe to our knowledge base and stay up to date on the expertise from the IT sector.

    About us

    The Codest – International software development company with tech hubs in Poland.

    United Kingdom - Headquarters

    • Office 303B, 182-184 High Street North E6 2JA
      London, England

    Poland - Local Tech Hubs

    • Fabryczna Office Park, Aleja
      Pokoju 18, 31-564 Kraków
    • Brain Embassy, Konstruktorska
      11, 02-673 Warsaw, Poland

      The Codest

    • Home
    • About us
    • Services
    • Case Studies
    • Know How
    • Careers
    • Dictionary

      Services

    • It Advisory
    • Software Development
    • Backend Development
    • Frontend Development
    • Staff Augmentation
    • Backend Developers
    • Cloud Engineers
    • Data Engineers
    • Other
    • QA Engineers

      Resources

    • Facts and Myths about Cooperating with External Software Development Partner
    • From the USA to Europe: Why do American startups decide to relocate to Europe
    • Tech Offshore Development Hubs Comparison: Tech Offshore Europe (Poland), ASEAN (Philippines), Eurasia (Turkey)
    • What are the top CTOs and CIOs Challenges?
    • The Codest
    • The Codest
    • The Codest
    • Privacy policy
    • Website terms of use

    Copyright © 2025 by The Codest. All rights reserved.

    en_USEnglish
    de_DEGerman sv_SESwedish da_DKDanish nb_NONorwegian fiFinnish fr_FRFrench pl_PLPolish arArabic it_ITItalian jaJapanese ko_KRKorean es_ESSpanish nl_NLDutch etEstonian elGreek en_USEnglish