O Gemfile.lock deve ser incluído no .gitignore?


501

Sou um pouco novo no empacotador e nos arquivos que ele gera. Eu tenho uma cópia de um repositório Git do GitHub que está sendo contribuído por muitas pessoas, então fiquei surpreso ao descobrir que o bundler criou um arquivo que não existia no repositório e não estava na .gitignorelista.

Como o bifurquei, sei que adicioná-lo ao repositório não quebrará nada no repositório principal, mas se eu fizer uma solicitação de recebimento, isso causará um problema?

Deve Gemfile.lockser incluído no repositório?



2
Se você encontrou seu caminho aqui porque possui caixas Linux e Windows compartilhando o mesmo repositório, consulte a resposta de Joe Yang. No momento da redação deste artigo, ele está em terceiro lugar. Veja também stackoverflow.com/questions/14034561/…
Peter Berg

Respostas:


549

Supondo que você não esteja escrevendo um rubygem, o Gemfile.lock deve estar no seu repositório. É usado como um instantâneo de todas as gemas necessárias e suas dependências. Dessa forma, o empacotador não precisa recalcular todas as dependências de gemas cada vez que você implanta, etc.

Do comentário de cowboycoded abaixo:

Se você estiver trabalhando em uma gema, NÃO faça check-in no seu Gemfile.lock. Se você estiver trabalhando em um aplicativo Rails, verifique seu Gemfile.lock.

Aqui está um bom artigo explicando o que é o arquivo de bloqueio.


88
Depende do que você está trabalhando. Se você estiver trabalhando em uma gema, NÃO faça check-in no seu Gemfile.lock. Se você estiver trabalhando em um aplicativo Rails, verifique seu Gemfile.lock. Mais informações aqui - yehudakatz.com/2010/12/16/…
johnmcaliley

Thx para artigo útil.
Ashisrai_

1
você deve colocar o que o código de cowboy disse na sua resposta re: gems.
Aarona

O link do artigo precisa de um novo href.
Ross

4
Por favor, não faça isso !! Mantenha o seu Gemfile.lock onde está! Como dito aqui e aqui .
Ricardo Ruwer

50

O verdadeiro problema acontece quando você está trabalhando em um aplicativo Rails de código aberto que precisa ter um adaptador de banco de dados configurável. Estou desenvolvendo a filial do Rails 3 do Fat Free CRM. Minha preferência é o postgres, mas queremos que o banco de dados padrão seja mysql2.

Nesse caso, Gemfile.lockainda é necessário fazer check-in com o conjunto padrão de gemas, mas preciso ignorar as alterações que fiz na máquina. Para fazer isso, eu corro:

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

e para reverter:

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

Também é útil incluir algo como o seguinte código no seu Gemfile. Isso carrega a gema apropriada do adaptador de banco de dados, com base no seu 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]
# -----------------------------------------------------------------------------

Não sei dizer se essa é uma prática recomendada estabelecida ou não, mas funciona bem para mim.


2
Informações muito úteis ... não sei por que você tem apenas 3 pontos e uma resposta menos útil tem 50 e alguns pontos. Ah, sim, olhe para os carimbos de data. (Uma das grandes falhas do SO é os benefícios desproporcionais que se obtêm a responder logo após a pergunta é feita.)
iconoclasta

1
@iconoclast: Estou muito feliz que você postou o que fez. Eu acho que muitas pessoas que vêm a este post, inclusive eu, estão "cegas" pelo título da pergunta. Agora percebo que minha resposta responde apenas a um caso de uso específico e não necessariamente a resposta certa para essa pergunta. Vou trabalhar para atualizá-lo em um futuro próximo. Dito isto, o OP não deveria ter marcado minha resposta como correta se não satisfizesse suas necessidades.
Rwilliams

34

Meus colegas de trabalho e eu temos diferentes Gemfile.lock, porque usamos diferentes plataformas, janelas e mac, e nosso servidor é linux.

Decidimos remover o Gemfile.lock no repo e criar o Gemfile.lock.server no git repo, assim como database.yml. Antes de implementá-lo no servidor, copiamos Gemfile.lock.server para Gemfile.lock no servidor usando o gancho de implantação de cap


5
Eu tenho um aplicativo que desenvolvo no OSX e preciso implantar em um servidor Windows. O rastreamento de Gemfile.lock com git provou ser uma péssima ideia, por isso foi no meu arquivo .gitignore. Muitas gemas requerem versões diferentes para os diferentes ambientes. Idealmente, você deve evitar sempre estar nesta situação, mas eu não tinha escolha (caramba, você departamento de TI!)
brad

11

Concordando com r-dub, mantenha-o no controle de origem, mas para mim, o benefício real é este:

colaboração em ambientes idênticos (desconsiderando as coisas windohs e linux / mac). Antes do Gemfile.lock, o próximo cara a instalar o projeto podia ver todos os tipos de erros confusos, culpando a si mesmo, mas ele era apenas esse cara de sorte recebendo a próxima versão do super gem, quebrando as dependências existentes.

Pior, isso aconteceu nos servidores, recebendo versão não testada, a menos que seja disciplinado e instale a versão exata. O Gemfile.lock torna isso explícito e explicitamente informa que suas versões são diferentes.

Nota: lembre-se de agrupar itens, como: development e: test


11

Os documentos do Bundler também abordam esta questão:

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

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

Consulte a seção "Verificando seu código no controle de versão":

Depois de desenvolver seu aplicativo por um tempo, faça o check-in junto com o instantâneo Gemfile e Gemfile.lock. Agora, seu repositório possui um registro das versões exatas de todas as gemas que você usou na última vez em que você tem certeza de que o aplicativo funcionou. Lembre-se de que enquanto seu Gemfile lista apenas três gemas (com vários graus de rigor da versão), seu aplicativo depende de dezenas de gemas, depois que você leva em consideração todos os requisitos implícitos das gemas das quais você depende.

Isso é importante: o Gemfile.lock transforma seu aplicativo em um único pacote, tanto do seu próprio código quanto do código de terceiros que ele executou na última vez em que você tem certeza de que tudo funcionou. Especificar versões exatas do código de terceiros dos quais você depende no seu Gemfile não forneceria a mesma garantia, porque as gemas geralmente declaram um intervalo de versões para suas dependências.

Na próxima vez que você executar a instalação do pacote na mesma máquina, o bundler verá que ele já possui todas as dependências necessárias e pulará o processo de instalação.

Não faça check-in no diretório .bundle ou em qualquer um dos arquivos contidos nele. Esses arquivos são específicos para cada máquina específica e são usados ​​para manter as opções de instalação entre as execuções do comando bundle install.

Se você executou o pacote configurável, os gems (embora não os git gems) exigidos pelo pacote configurável serão baixados no fornecedor / cache. O Bundler pode ser executado sem conectar-se à Internet (ou ao servidor RubyGems) se todas as gemas necessárias estiverem presentes nessa pasta e registradas no seu controle de origem. Esta é uma etapa opcional, e não recomendada, devido ao aumento no tamanho do seu repositório de controle de origem.


4

Nenhum Gemfile.lock significa:

  • novos colaboradores não podem executar testes porque coisas estranhas falham, então eles não contribuem ou obtêm PRs com falha ... primeira experiência ruim.
  • você não pode voltar ao projeto do ano anterior e corrigir um erro sem precisar atualizar / reescrever o projeto se você perdeu o Gemfile.lock local

-> Sempre verifique o Gemfile.lock, faça o travis excluí-lo se quiser ser mais completo https://grosser.it/2015/08/14/check-in-your-gemfile-lock/


3

Um pouco atrasado para a festa, mas as respostas ainda me levaram tempo e leituras estrangeiras para entender esse problema. Então, quero resumir o que descobri sobre o Gemfile.lock.

Ao criar um aplicativo Rails, você está usando determinadas versões de gemas na sua máquina local. Se você deseja evitar erros no modo de produção e em outras ramificações, use esse arquivo Gemfile.lock em todos os lugares e peça ao bundler bundlepara reconstruir gemas toda vez que mudar.

Se você Gemfile.lockmudou na sua máquina de produção e o Git não permite git pull, você deve escrever git reset --hardpara evitar essa alteração no arquivo e escrever git pullnovamente.


Se um arquivo for alterado automaticamente, por exemplo, por um processo de construção, é um sinal claro de que não deve ser adicionado ao controle de versão.
Thomas S.
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.