Debe Gemfile.cerradura ser incluido adentro.gitignore?

El verdadero problema ocurre cuando se 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.lock todavía necesita ser revisado con el conjunto predeterminado de gemas, pero necesito ignorar los cambios que he hecho en mi máquina. Para lograr esto, corro:

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

Y para invertir:

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

Es 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, en función de su base de datos.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 buena práctica establecida o no, pero funciona bien para mí.

Mis compañeros de trabajo y yo tenemos un Gemfile diferente.bloquear, porque utilizamos diferentes plataformas, windows y mac, y nuestro servidor es linux.

Decidimos eliminar Gemfile.bloquear repo y crear Gemfile.bloqueo.servidor en repositorio git, al igual que la base de datos.yml. Luego, antes de implementarlo en el servidor, copiamos Gemfile.bloqueo.servidor a Gemfile.bloquear el servidor usando cap deploy hook

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

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

Peor aún, esto sucedió en los servidores, obteniendo la versión no probada a menos que ser disciplinado e instalar la versión exacta. Gemfile.lock hace esto explícito, y te dirá explícitamente que tus versiones son diferentes.

Nota: recuerde agrupar cosas, como :development y: test

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 "Comprobación de su Código en el Control de versiones":

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

Esto es importante: el Gemfile.lock hace que su aplicación sea una paquete de su propio código y el código de terceros ejecutó el último es hora de que sepas con certeza que todo funcionó. Especificación exacta las versiones del código de terceros del que depende en su Gemfile serían no proporcionan la misma garantía, porque las gemas generalmente declaran un rango de versiones para sus dependencias.

La próxima vez que ejecute bundle install en la misma máquina, bundler vea que ya tiene todas las dependencias que necesita, y omita la proceso de instalación.

No compruebe en el .bundle, o cualquiera de los archivos dentro de él. Esos archivos son específicos para cada máquina en particular, y se utilizan para opciones de instalación persistentes entre ejecuciones de la instalación del paquete comando.

Si has ejecutado bundle pack, las gemas (aunque no las gemas de git) requerido por su paquete se descargará en vendor / cache. 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 fuente. Este es un paso opcional, y no se recomienda, debido al aumento de tamaño de su repositorio de control de código fuente.

Un poco tarde para la fiesta, pero las respuestas todavía me llevó tiempo y lecturas extranjeras para entender este problema. Así que quiero resumir lo que he averiguado sobre el Gemfile.bloqueo.

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 Gemfile.bloquee el archivo en todas partes y dígale a bundler que bundle para reconstruir gemas cada vez que cambie.

Si Gemfile.lock ha cambiado en su máquina de producción y Git no le permite git pull, debe escribir git reset --hard para evitar ese cambio de archivo y escribir git pull de nuevo.

No hay Gemfile.lock significa:

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

-> Compruebe siempre el Gemfile.lock, haz que Travis lo borre si quieres ser extra minucioso https://grosser.it/2015/08/14/check-in-your-gemfile-lock /