2011-06-29 20 views
19

así que lo que estoy sugiriendo en mi trabajo, es poner db/schema.rb en el archivo .gitignore, por lo que no tenemos (ocasionalmente) problemas de fusión.¿Es una buena idea poner db/schema.rb en .gitignore list ??

Existen algunas preocupaciones de que si ocurre algo terrible (caída de meteoritos del cielo directamente en el servidor de bases de datos y simultáneamente todos los archivos db/migrete están dañados) podríamos perder el esquema, y ​​tendremos que usar rake db: purgar (para reutilizar schema.rb). Estoy de acuerdo en que esto es posible y es un buen argumento, pero no debería ser un problema porque db/schema.rb se genera cada vez que realizamos rake db: migrate. Así que aunque no introduzcamos schema.rb en el servidor, estamos impulsando que las migraciones agreguen ejecutando db: migrar cada vez que estamos implementando con cambios en las bases de datos y con eso db: migrate rails generará automáticamente schema.rb en el servidor, y eso schema.rb permanece sin cambios en el servidor hasta que hagamos otro db: migrar.

así que ¿cuál es su opinión, deberíamos o no deberíamos poner el db/schema.rb en git ignorar?

agradecimiento

+1

posible duplicado de [¿Cuál es el enfoque correcto para tratar con el archivo Rails db/schema.rb en GIT?] (Http: // stackoverflow.com/preguntas/6450263/que-es-la-derecha-enfoque-a-acuerdo-con-carriles-db-esquema-rb-archivo-en-GIT) –

+0

Darn, yo estaba muy orgulloso de mi respuesta :) lo siento – VonC

+0

pero el enlace es demasiado convincente :(, pero gracias por la ayuda – equivalent8

Respuesta

30

Siempre sugiero mantener schema.rb en la versión contol, ya que tareas como rake db: schema: load dependen de que esté allí.

Acerca de los conflictos, ¿está hablando de los conflictos de versión de esquema? Estos se mitigan fácilmente utilizando el algoritmo de fusión que se muestra aquí: http://tbaggery.com/2010/10/24/reduce-your-rails-schema-conflicts.html

Otros conflictos, como las ubicaciones de cambio de definición de columna, se pueden evitar fácilmente teniendo cuidado con lo que se compromete con el repositorio.

+1

+1 para el enlace, buena idea – MBO

+0

sí, estoy hablando de conflictos git (VSC), el enlace que publiqué es realmente una buena idea, lo pensaré (+1) – equivalent8

4

Usted debe poner en un VCS lo que sea necesario para reproducir un entorno operativo.
Si, para reconstruir su aplicación, necesita tener el schema.rb correcto (en la versión correcta), entonces sí, puede ser versionado.

Pero si puede recuperarlo a través de otro proceso, entonces es mejor respaldarlo a través de otro referencial que un VCS.

+0

bien, el argumento dado por el beneficio de no colocar a .gitignore :) – equivalent8

+1

@equivalent: sí, es por eso que he upvoted [respuesta de Martijn] (http: //stackoverflow.com/questions/6520017/is-a-good-idea-to-put-db-schema-rb-to-gitignore-list/6520115#6520115), que incluye el caso real donde 'schema.rb' es necesario. – VonC

+1

el archivo schema.rb contiene el siguiente texto: "Se recomienda encarecidamente verificar este archivo en su sistema de control de versiones". – hlegius

4

Al cambiar entre las ramas de características que se desarrollan un conjunto diferente de atributos de modelo, a continuación, sin schema.rb a veces se tendría que:

  1. rake db:migrate:down VERSION=xxx migraciones que eran crear hace algún tiempo, pero no se fusionó con otras ramas
  2. git checkout branch
  3. rake db:migrate migrar todas las ramas de nueva creación

que encuentro som Problemas con esto en proyectos anteriores donde schema.rb estaba en .gitignore. Cada vez que veo que algo andaba mal, tenía que eliminar la base de datos y volver a crear desde las migraciones, mientras que con schema.rb solo podía cargar el esquema en una fracción de segundo y luego rake db:seed para cargar datos. Pero no fue crítico.

También me interesan los problemas que tiene con la fusión de schema.rb? La mayoría de las veces puede anular este archivo sin preocuparse por los cambios (supongo que no ha modificado la estructura de la base de datos a mano) con rake db:dump y simplemente agréguelo como resolución de fusión.

Cuestiones relacionadas