references rails railroady migrations create ruby-on-rails git workflow schema.rb

ruby-on-rails - railroady - rails references



¿Cuál es la forma preferida de administrar schema.rb en git? (8)

No quiero agregar schema.rb a .gitignore , porque quiero poder cargar un nuevo esquema de base de datos desde ese archivo. Sin embargo, mantenerlo registrado está causando todo tipo de conflictos espurios que se resuelven fácilmente con un nuevo db:migrate:reset .

Básicamente quiero una manera de:

  1. Mantenga schema.rb en el repositorio para la configuración de la base de datos en tiempo de implementación
  2. Mantenga schema.rb en ''.gitignore'' para el desarrollo general

Habría una o dos personas responsables de actualizar schema.rb y saber que era correcto.

¿Hay alguna manera de que pueda tener mi pastel y comerlo, también?


  1. Cometer archivo schema.rb .
  2. Ejecuta git pull (o continúa con lo que estás haciendo)

Cada vez que migra la base de datos, el archivo schema.rb actualiza y aparece en git status . Cuando trabajas en algo y ocasionalmente haces git pull , esto puede ser molesto porque tienes que cometer el archivo schema.rb antes de tirar para resolver conflictos. Esto significa que cada vez que migre la base de datos, debe confirmar el archivo schema.rb .


¿Sería suficiente hacer un rake db: dump en un gancho de git pre-commit?

Lo siguiente no necesariamente solucionará (1) o (2), pero puede solucionar el problema de fusión, y luego tal vez (1) y (2) desaparezcan.


Construí una gema para resolver este problema.

Ordena las columnas, los nombres de los índices y las claves externas, elimina el exceso de espacios en blanco y ejecuta Rubocop en algunos formatos para unificar la salida de su archivo schema.rb.

https://github.com/jakeonrails/fix-db-schema-conflicts

Después de agregarlo a su Gemfile, simplemente ejecuta rake db:migrate o rake db:schema:dump como normal.


En lugar de usar .gitignore , use ramas separadas: Develop que omita schema.rb y Test and Deploy que incluyen schema.rb . Solo realice cambios de código en las ramas de Desarrollo y nunca fusione de Test a Develop . Mantenga schema.rb en una rama separada:

Developer A Develop -------- Local Schema / Your Repo Test ---------> Dev A ---------> Dev B Developer B / Master Develop -------- Schema Local Schema Test Test Deploy

En Git, las ramas son punteros a colecciones de contenidos de archivos, por lo que pueden incluir o excluir archivos particulares así como también versiones de archivos de seguimiento. Esto los hace herramientas flexibles para construir su flujo de trabajo particular.


Lo que me ha funcionado muy bien es eliminar y .gitignore schema.rb y luego regenerarlo para cada desarrollador cuando rake db:migrate .

Aún puede lograr lo que quería sin migrar de 0 y arriesgarse a migraciones interrumpidas de hace años simplemente haciendo un "roll-up" de las migraciones periódicamente. Puedes hacer esto por:

  1. Ejecute todas las migraciones pendientes con rake db:migrate
  2. Tomando el contenido de su schema.rb en el bloque ActiveRecord::Schema.define
  3. Péguelo en su migración inicial_esquema dentro de la def up (sobrescribiendo lo que ya existe)
  4. Eliminar todas las demás migraciones

Ahora, la migración de initial_schema es su punto de partida para nuevos sistemas y no tiene que preocuparse por los conflictos en schema.rb que pueden no resolverse correctamente. No es mágico, pero funciona.


Me temo que la solución mágica que estás buscando no existe. Este archivo normalmente se administra en el control de versiones, luego, para cualquier conflicto en la línea de la versión, simplemente elija la última de las dos fechas. Mientras esté ejecutando todas las migraciones asociadas, nada debería desincronizarse de esta manera. Si dos desarrolladores han provocado modificaciones en un área similar de schema.rb y usted obtiene conflictos además de la versión, entonces se enfrenta a una resolución de conflicto de combinación normal, pero en mi opinión, normalmente son fáciles de entender y resolver. ¡Espero que esto ayude algo!


Otra cosa que puedes hacer es usar:

git update-index --assume-unchanged /path/schema.rb

Esto mantendrá el archivo en el repositorio pero no rastreará los cambios. Puedes cambiar el seguimiento en cualquier momento usando:

git update-index --no-assume-unchanged /path/schema.rb


Podrías definir una estrategia de fusión. He encontrado esta solución, pero no recuerdo la fuente

[merge "railsschema"] name = newer Rails schema version driver = "ruby -e ''/n/ system %(git), %(merge-file), %(--marker-size=%L), %(%A), %(%O), %(%B)/n/ b = File.read(%(%A))/n/ b.sub!(/^<+ .*//nActiveRecord::Schema//.define.:version => (//d+). do//n=+//nActiveRecord::Schema//.define.:version => (//d+). do//n>+ .*/) do/n/ %(ActiveRecord::Schema.define(:version => #{[$1, $2].max}) do)/n/ end/n/ File.open(%(%A), %(w)) {|f| f.write(b)}/n/ exit 1 if b.include?(%(<)*%L)''"

Pon este "en algún lugar" y

git-config --global core.attributesfile "somewhere"