¿Debería incluirse Gemfile.lock en .gitignore?


501

Soy nuevo en bundler y los archivos que genera. Tengo una copia de un repositorio git de GitHub al que contribuyen muchas personas, por lo que me sorprendió descubrir que el paquete creó un archivo que no existía en el repositorio y no estaba en la .gitignorelista.

Dado que lo bifurqué, sé que agregarlo al repositorio no romperá nada para el repositorio principal, pero si hago una solicitud de extracción, ¿causará un problema?

¿Debería Gemfile.lockincluirse en el repositorio?



2
Si encontró su camino aquí porque tiene cajas de Linux y Windows que comparten el mismo repositorio, vea la respuesta de Joe Yang. En el momento de escribir esto, ocupa el tercer lugar. Ver también stackoverflow.com/questions/14034561/…
Peter Berg

Respuestas:


549

Suponiendo que no esté escribiendo un rubygem, Gemfile.lock debería estar en su repositorio. Se utiliza como una instantánea de todas sus gemas requeridas y sus dependencias. De esta manera, el paquete no tiene que volver a calcular todas las dependencias de gemas cada vez que implementa, etc.

Del comentario de cowboycoded a continuación:

Si está trabajando en una gema, NO revise su Gemfile.lock. Si está trabajando en una aplicación Rails, entonces verifique su Gemfile.lock.

Aquí hay un buen artículo que explica qué es el archivo de bloqueo.


88
Depende de lo que estés trabajando. Si está trabajando en una gema, NO revise su Gemfile.lock. Si está trabajando en una aplicación Rails, entonces verifique su Gemfile.lock. Más información aquí - yehudakatz.com/2010/12/16/…
johnmcaliley

Gracias por un artículo útil.
ashisrai_

1
deberías poner lo que dijo cowboycoded en tu respuesta sobre gemas.
aarona

El enlace del artículo necesita un nuevo href.
Ross

44
¡Por favor no hagas eso! ¡Mantenga su Gemfile.lock donde está! Como dijo aquí y aquí .
Ricardo Ruwer

50

El verdadero problema ocurre cuando está trabajando en una aplicación Rails de código abierto que necesita tener un adaptador de base de datos configurable. Estoy desarrollando la rama Rails 3 de Fat Free CRM. Mi preferencia es postgres, pero queremos que la base de datos predeterminada sea mysql2.

En este caso, Gemfile.locktodavía es necesario que se registre con el conjunto predeterminado de gemas, pero debo ignorar los cambios que le hice en mi máquina. Para lograr esto, ejecuto:

git update-index --assume-unchanged Gemfile.lock

y para revertir:

git update-index --no-assume-unchanged Gemfile.lock

También es útil incluir algo como el siguiente código en su Gemfile. Esto carga la gema de adaptador de base de datos adecuada, basada en su database.yml.

# Loads the database adapter gem based on config/database.yml (Default: mysql2)
# -----------------------------------------------------------------------------
db_gems = {"mysql2"     => ["mysql2", ">= 0.2.6"],
           "postgresql" => ["pg",     ">= 0.9.0"],
           "sqlite3"    => ["sqlite3"]}
adapter = if File.exists?(db_config = File.join(File.dirname(__FILE__),"config","database.yml"))
  db = YAML.load_file(db_config)
  # Fetch the first configured adapter from config/database.yml
  (db["production"] || db["development"] || db["test"])["adapter"]
else
  "mysql2"
end
gem *db_gems[adapter]
# -----------------------------------------------------------------------------

No puedo decir si esta es una mejor práctica establecida o no, pero me funciona bien.


2
Información muy útil ... no estoy seguro de por qué solo tienes 3 puntos y una respuesta menos útil tiene 50 puntos. Oh, sí, mira los sellos de fecha. (Uno de los grandes fracasos de SO es los beneficios desproporcionados que se acumulan a responder poco después se hace la pregunta.)
iconoclasta

1
@iconoclast: Estoy muy contento de que hayas publicado lo que hiciste. Creo que muchas personas que vienen a esta publicación, incluido yo mismo, están "cegadas" por el título de la pregunta. Ahora me doy cuenta de que mi respuesta solo responde a un caso de uso específico y no necesariamente la respuesta correcta a esta pregunta. Trabajaré para actualizarlo en un futuro próximo. Dicho esto, el OP no debería haber marcado mi respuesta como correcta si no satisfacía sus necesidades.
rwilliams

34

Mis compañeros de trabajo y yo tenemos Gemfile.lock diferente, porque usamos diferentes plataformas, Windows y Mac, y nuestro servidor es Linux.

Decidimos eliminar Gemfile.lock en repo y crear Gemfile.lock.server en git repo, al igual que database.yml. Luego, antes de implementarlo en el servidor, copiamos Gemfile.lock.server a Gemfile.lock en el servidor usando cap deploy hook


55
Tengo una aplicación que desarrollo en OSX y luego tengo que implementar en un servidor de Windows. El seguimiento de Gemfile.lock con git demostró ser una mala idea, por lo que entró en mi archivo .gitignore. Muchas gemas requieren diferentes versiones para los diferentes entornos. Idealmente, deberías evitar estar en esta situación, pero no tuve otra opción (¡maldito departamento de TI!)
Brad

11

De acuerdo con r-dub, manténgalo en control de la fuente, pero para mí, el beneficio real es este:

colaboración en entornos idénticos (sin tener en cuenta las ventanas y las cosas de linux / mac). Antes de Gemfile.lock, el siguiente tipo en instalar el proyecto podría ver todo tipo de errores confusos, culpándose a sí mismo, pero era solo ese tipo afortunado que obtenía la próxima versión de super gem, rompiendo las dependencias existentes.

Peor aún, esto sucedió en los servidores, obteniendo una versión no probada a menos que sea disciplinado e instale la versión exacta. Gemfile.lock lo hace explícito, y explícitamente le dirá que sus versiones son diferentes.

Nota: recuerde agrupar cosas, como: desarrollo y: prueba


11

Los documentos de Bundler también abordan esta pregunta:

ORIGINAL: http://gembundler.com/v1.3/rationale.html

EDITAR: http://web.archive.org/web/20160309170442/http://bundler.io/v1.3/rationale.html

Consulte la sección llamada "Verificación de su código en el control de versiones":

Después de desarrollar su aplicación por un tiempo, registre la aplicación junto con la instantánea Gemfile y Gemfile.lock. Ahora, su repositorio tiene un registro de las versiones exactas de todas las gemas que utilizó la última vez que sabe con certeza que la aplicación funcionó. Tenga en cuenta que si bien su Gemfile enumera solo tres gemas (con diversos grados de rigor de versión), su aplicación depende de docenas de gemas, una vez que tenga en cuenta todos los requisitos implícitos de las gemas de las que depende.

Esto es importante: Gemfile.lock hace que su aplicación sea un paquete único tanto de su propio código como del código de terceros que ejecutó la última vez que sabe con seguridad que todo funcionó. Especificar versiones exactas del código de terceros del que depende en su Gemfile no proporcionaría la misma garantía, porque las gemas generalmente declaran un rango de versiones para sus dependencias.

La próxima vez que ejecute la instalación de paquete en la misma máquina, el paquete verá que ya tiene todas las dependencias que necesita y omitirá el proceso de instalación.

No consulte el directorio .bundle ni ninguno de los archivos que contiene. Esos archivos son específicos de cada máquina en particular y se usan para mantener las opciones de instalación entre ejecuciones del comando de instalación de paquete.

Si ha ejecutado el paquete de paquetes, las gemas (aunque no las gemas git) requeridas por su paquete se descargarán en el proveedor / caché. Bundler puede ejecutarse sin conectarse a Internet (o al servidor RubyGems) si todas las gemas que necesita están presentes en esa carpeta y se registraron en su control de origen. Este es un paso opcional, y no recomendado, debido al aumento en el tamaño de su repositorio de control de código fuente.


4

Sin Gemfile.lock significa:

  • los nuevos contribuyentes no pueden ejecutar pruebas porque fallan cosas extrañas, por lo que no contribuirán ni obtendrán PR fallidos ... mala primera experiencia.
  • no puede volver al proyecto de un año y corregir un error sin tener que actualizar / reescribir el proyecto si perdió su Gemfile.lock local

-> Siempre verifique en Gemfile.lock, haga que Travis lo elimine si desea ser más exhaustivo https://grosser.it/2015/08/14/check-in-your-gemfile-lock/


3

Un poco tarde para la fiesta, pero las respuestas todavía me tomaron tiempo y lecturas extranjeras para entender este problema. Así que quiero resumir lo que he descubierto sobre Gemfile.lock.

Cuando está creando una aplicación Rails, está utilizando ciertas versiones de gemas en su máquina local. Si desea evitar errores en el modo de producción y otras ramas, debe usar ese único archivo Gemfile.lock en todas partes y decirle al agrupador que bundlereconstruya las gemas cada vez que cambie.

Si Gemfile.lockha cambiado en su máquina de producción y Git no lo deja git pull, debe escribir git reset --hardpara evitar ese cambio de archivo y git pullvolver a escribir .


Si un archivo cambia automáticamente, por ejemplo, mediante un proceso de compilación, es una señal clara de que no debe agregarse al control de versiones.
Thomas S.
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.