2011-09-30 16 views
46

Ho creato una migrazione, eseguito , che ha superato il mio numero di versione db/schema.rb. Poi ho fatto un git fetch origin master e ho visto che c'erano dei cambiamenti dai membri del mio team. Così ho fatto uno git stash e uno git rebase FETCH_HEAD, seguito da uno git stash pop. Ciò ha provocato un conflitto in db/schema.rb sul numero di versione.Gestione conflitto in schema.rb creato dall'operazione Git

Upstream>>> 
ActiveRecord::Schema.define(:version => 20110930179257) do 
=========== 
ActiveRecord::Schema.define(:version => 20110930161932) do 
<<<Stashed 

Penso che la soluzione appropriata sarebbe quella di incrementare manualmente il numero di versione a qualcosa di più alto rispetto al monte.

È questa sensata o cattiva notizia?

Grazie, Max

+1

Per rispondere alla mia domanda, incrementando manualmente la versione il numero non è necessario e, con ogni probabilità, una cattiva idea. Tutto ciò che è necessario, da quello che posso dire, è accettare semplicemente il numero di versione upstream. – maxenglander

risposta

81

Se il database corrente ha lo schema corretto, si dovrebbe:

  • Run attesa migrazioni (se presenti)

    rake db:migrate 
    
  • sovrascrivere il schema.rb da lo schema attuale del database

    rake db:schema:dump 
    
  • e impegnarsi

+0

Non sono sicuro se questo funziona nella mia situazione. Ho avuto migrazioni in sospeso da upstream. – maxenglander

+10

Se si hanno migrazioni in sospeso, eseguirle quindi 'rake db: schema: dump' – Xorlev

+0

Non creerebbe una richiesta di pull senza modifiche alla versione in schema.rb, se la versione del telecomando è più alta? –

0

Un'opzione è quella di avere uno script versione manuale che è additiva solo. Lì vuoi conflitti. Lo schema è qualcosa che ti morde duramente se non tieni duro sopra. Quindi, una volta morso, due volte timido, non mi interessa mantenere lo schema e le informazioni di ricerca (elenco dei tipi di clienti) con uno schema di gestione delle modifiche solo additivo.

6

In base a this answer, è garantito un conflitto. L'utente deve unire manualmente e impostare la versione come la più alta delle due.

16

Quando mi trovo in questo conflitto, eseguo semplicemente la migrazione del database. In caso di migrazioni in sospeso o meno, il conflitto verrà corretto.

+0

risposta migliore, grazie – dowi

0

Ritengo che l'approccio migliore sia eseguire rake db:drop db:create db:migrate per rigenerare lo schema utilizzando le migrazioni esistenti solo sul ramo corrente. In questo modo le migrazioni da altri rami non coleranno nel tuo file di schema e ti daranno il mal di testa più tardi, nel caso in cui cambi succursali molto.

2

Ecco quello che faccio quando la fusione maestro nel mio ramo della funzione failover conflitti in db/schema.rb:

$ git merge --abort 
$ git checkout master 
$ rake db:drop db:create db:migrate 
$ git checkout -- db/schema.rb 
$ git checkout my_feature_branch 
$ rake db:migrate 
$ git add db/schema.rb 
$ git commit -m 'Updated schema' 
$ git merge master 
1

~/bin/update-schema-rb:

#!/usr/bin/env bash 

git co master 
bin/rake db:reset db:seed 
git co - 
bin/rake db:migrate 
Problemi correlati