Estou desenvolvendo o iOS há alguns meses e acabei de conhecer a promissora biblioteca CocoaPods para gerenciamento de dependências.

Eu tentei em um projeto pessoal: adicionei uma dependência do Kiwi ao meu Podfile, executei pod install CocoaPodsTest.xcodeproje pronto , funcionou muito bem.

A única coisa que me resta a perguntar é: o que eu faço check-in e o que eu ignoro para o controle de versão? Parece óbvio que desejo fazer o check-in no próprio Podfile e, provavelmente, no arquivo .xcworkspace; mas ignoro o diretório Pods /? Existem outros arquivos que serão gerados no caminho (quando adiciono outras dependências) que também devo adicionar ao meu .gitignore?

Pessoalmente, não verifico o diretório e o conteúdo dos Pods. Não posso dizer que passei longas eras considerando as implicações, mas meu raciocínio é algo como:

O Podfile refere-se a uma tag ou confirmação específica de cada dependência, para que os próprios Pods possam ser gerados a partir do podfile, portanto, são mais um produto intermediário de compilação do que uma fonte e, portanto, não precisam de controle de versão no meu projeto.

Eu comprometo meu diretório de pods. Não concordo que o diretório Pods seja um artefato de construção. Na verdade, eu diria que definitivamente não é. Faz parte da fonte do seu aplicativo: não será construído sem ele!

É mais fácil pensar no CocoaPods como uma ferramenta de desenvolvedor, em vez de uma ferramenta de construção. Ele não cria seu projeto, simplesmente clona e instala suas dependências para você. Não deve ser necessário ter o CocoaPods instalado para poder simplesmente construir seu projeto.

Ao tornar o CocoaPods uma dependência de sua compilação, agora você precisa garantir que ele esteja disponível em qualquer lugar que você precise para criar seu projeto ... um administrador de equipe precisa, seu servidor de CI precisa. Como regra, você sempre deve poder clonar seu repositório de origem e criar sem nenhum esforço adicional.

Não comprometer o diretório Pods também cria uma enorme dor de cabeça se você alternar frequentemente as ramificações. Agora você precisa executar a instalação do pod toda vez que alternar ramificações para garantir que suas dependências estejam corretas. Isso pode ser menos problemático, pois suas dependências se estabilizam, mas no início de um projeto, esse é um grande sumidouro de tempo.

Então, o que eu ignoro? Nada. Podfile, o arquivo de bloqueio e o diretório Pods são confirmados. Confie em mim, você vai economizar muito aborrecimento. Quais são os contras? Um repo um pouco maior? Não é o fim do mundo.

Eu recomendo usar o gitignore Objective-C do GitHub . Em detalhes, as melhores práticas são:

• O Podfile deve sempre estar sob controle de origem.
• O Podfile.lock deve sempre estar sob controle de origem.
• O espaço de trabalho gerado pelo CocoaPods deve ser mantido sob controle de origem.
• Qualquer Pod referenciado com a :pathopção deve ser mantido sob controle de origem.
• A ./Podspasta pode ser mantida sob controle de origem.

Para mais informações, consulte o guia oficial .

fonte: sou membro da equipe principal do CocoaPods, como @alloy

Embora a pasta Pods seja um artefato de construção, há alguns motivos que você pode considerar ao decidir se deseja mantê-la sob controle de origem:

• O CocoaPods não é um gerenciador de pacotes; portanto, a fonte original da biblioteca pode ser removida no futuro pelo autor.
• Se a pasta Pods estiver incluída no controle de origem, não será necessário instalar o CocoaPods para executar o projeto, pois a finalização da compra seria suficiente.
• O CocoaPods ainda está em andamento e há opções que nem sempre levam ao mesmo resultado (por exemplo, :headas :gitopções e atualmente não estão usando os commits armazenados no Podfile.lock).
• Existem menos pontos de falha se você puder retomar o trabalho em um projeto após um período médio / longo.

arquivo .gitignore

Nenhuma resposta realmente oferece uma.gitignore , então aqui estão dois sabores.

Verificando no diretório Pods ( Benefícios )

O git amigável para Xcode / iOS ignora, pulando arquivos de sistema Mac OS, Xcode, builds, outros repositórios e backups.

.gitignore:

# Mac OS X Finder
.DS_Store

# Private Keys
*.pem

# Xcode legacy
*.mode1
*.mode1v3
*.mode2v3
*.perspective
*.perspectivev3
*.pbxuser

# Xcode
xcuserdata/
project.xcworkspace/
DerivedData/

# build products
build/
*.[oa]

# repositories
.hg
.svn
CVS

# automatic backup files
*~.nib
*.swp
*~
*(Autosaved).rtfd/
Backup[ ]of[ ]*.pages/
Backup[ ]of[ ]*.key/
Backup[ ]of[ ]*.numbers/

Ignorando o diretório Pods ( Benefícios )

.gitignore: (anexar à lista anterior)

# Cocoapods
Pods/

Quer você verifique ou não o diretório Pods, o Podfile e o Podfile.lock devem sempre ser mantidos sob controle de versão.

Se Podsnão houver check-in, você Podfileprovavelmente deverá solicitar números de versão explícitos para cada Cocoapod. Discussão sobre Cocoapods.org aqui .

Eu geralmente trabalho em aplicativos de clientes. Nesse caso, também adiciono o diretório Pods ao repositório, para garantir que a qualquer momento qualquer desenvolvedor possa fazer um checkout, criar e executar.

Se fosse um aplicativo próprio, provavelmente excluiria o diretório Pods até não trabalhar nele por um tempo.

Na verdade, devo concluir que posso não ser a melhor pessoa para responder à sua pergunta, em comparação com as opiniões de usuários puros :) Vou twittar sobre essa pergunta em https://twitter.com/CocoaPodsOrg .

Eu verifico tudo. ( Pods/ePodfile.lock .)

Quero poder clonar o repositório e saber que tudo funcionará como na última vez que usei o aplicativo.

Prefiro coisas do fornecedor do que correr o risco de ter resultados diferentes que podem ser causados ​​por uma versão diferente da gema ou por alguém reescrever o histórico no repositório do Pod, etc.

A resposta para isso é fornecida diretamente nos documentos do Cocoapod. Você pode consultar " http://guides.cocoapods.org/using/using-cocoapods.html#should-i-ignore-the-pods-directory-in-source-control "

A decisão de verificar ou não a pasta Pods depende de você, pois os fluxos de trabalho variam de projeto para projeto. Recomendamos que você mantenha o diretório Pods sob controle de origem e não o adicione ao seu .gitignore. Mas, finalmente, esta decisão é sua:

Benefícios da verificação no diretório Pods

• Após a clonagem do repositório, o projeto pode ser executado e executado imediatamente, mesmo sem os CocoaPods instalados na máquina. Não é necessário executar a instalação do pod e nenhuma conexão com a Internet é necessária.
• Os artefatos do Pod (código / bibliotecas) estão sempre disponíveis, mesmo se a fonte de um Pod (por exemplo, GitHub) fosse desativada.
• É garantido que os artefatos do Pod sejam idênticos aos da instalação original após a clonagem do repositório.

Benefícios de ignorar o diretório Pods

• O repositório de controle de origem será menor e ocupará menos espaço.

• Enquanto as fontes (por exemplo, GitHub) para todos os Pods estiverem disponíveis, o CocoaPods geralmente poderá recriar a mesma instalação. (Tecnicamente, não há garantia de que a instalação do pod em execução busque e recrie artefatos idênticos quando não estiver usando um SHA de confirmação no Podfile. Isso é especialmente verdade ao usar arquivos zip no Podfile.)

• Não haverá conflitos para lidar ao executar operações de controle de origem, como mesclar ramificações com diferentes versões do Pod.

Quer você verifique ou não o diretório Pods, o Podfile e o Podfile.lock devem sempre ser mantidos sob controle de versão.

Estou no campo de desenvolvedores que não fazem check-in de bibliotecas, assumindo que temos uma boa cópia disponível em outro local. Portanto, no meu .gitignore, incluo as seguintes linhas específicas para o CocoaPods:

Pods/
#Podfile.lock  # changed my mind on Podfile.lock

Então, garanto que temos uma cópia das bibliotecas em um local seguro. Em vez de (mis-) usar o repositório de código de um projeto para armazenar dependências (compiladas ou não), acho que a melhor maneira de fazer isso é arquivar compilações. Se você usar um servidor de IC para suas construções (como Jenkins), poderá arquivar permanentemente todas as construções importantes para você. Se você criar todas as suas construções de produção no Xcode local, crie o arquivo do seu projeto para todas as construções que você precisa manter. Algo como: 1. Produto -> Arquivo

1. Distribua ... Envie para a App Store do iOS / Salvar para empresa ou Implantação ad-hoc / o que você tem

2. Revele a pasta do seu projeto no Finder

3. Clique com o botão direito e Comprima "WhateverProject"

Isso fornece uma imagem como construída de todo o projeto, incluindo as configurações completas do projeto e da área de trabalho usadas para criar o aplicativo, bem como distribuições binárias (como Sparkle, SDKs proprietários como TestFlight etc.), independentemente de eles usarem ou não o CocoaPods.

Atualização: Eu mudei de idéia sobre isso e agora confirmo o Podfile.lockcontrole de origem. No entanto, ainda acredito que os próprios pods são artefatos de construção e devem ser gerenciados como tal fora do controle de origem, através de outro método, como o servidor de IC ou um processo de arquivamento, como descrevi acima.

Prefiro confirmar o Podsdiretório juntamente com Podfilee Podfile.lockgarantir que alguém da minha equipe possa fazer o checkout da fonte a qualquer momento e não precise se preocupar com nada ou fazer outras coisas para fazê-la funcionar.

Isso também ajuda em um cenário em que você corrigiu um bug em um dos pods ou modificou algum comportamento conforme suas necessidades, mas essas alterações não estarão disponíveis em outras máquinas se não forem confirmadas.

E para ignorar diretórios desnecessários:

xcuserdata/

Devo dizer que sou fã de comprometer Pods no repositório. Seguir um link já mencionado dará a você um bom arquivo .gitignore para atualizar seus projetos Xcode para iOS para permitir Pods, mas também para excluí-los facilmente, se assim o desejar: https://github.com/github/gitignore/ blob / master / Objective-C.gitignore

Meu raciocínio para ser um fã de adicionar Pods ao repositório é por um motivo fundamental que ninguém parece entender: o que acontece se uma biblioteca da qual nosso projeto é tão dependente é subitamente removida da Web?

• Talvez o host decida que não deseja mais manter sua conta do GitHub aberta. O que acontece se a biblioteca tiver vários anos (por exemplo, mais de 5 anos, por exemplo), há um alto risco de o projeto não estar mais disponível na fonte
• Outro ponto: o que acontece se a URL do repositório mudar? Digamos que a pessoa que atende o Pod a partir de sua conta do GitHub, decida se apresentar de outra maneira - seus URLs de Pods serão quebrados.
• Finalmente outro ponto. Digamos que se você é um desenvolvedor como eu, que codifica bastante em um voo entre países. Faço um puxão rápido na ramificação 'master', instalo um pod nessa ramificação, enquanto estou sentado no aeroporto e me preparei para o próximo vôo de 8 horas. Recebo 3 horas de voo e percebo que preciso mudar para outro ramo .... 'DOH' - faltam informações de Pod que só estão disponíveis no ramo 'mestre'.

NB ... observe que a ramificação 'master' para desenvolvimento é apenas um exemplo; obviamente, as ramificações 'master' nos sistemas de controle de versão devem ser mantidas limpas e implantáveis ​​/ montáveis ​​a qualquer momento

Eu acho que disso, instantâneos nos repositórios de código são certamente melhores do que serem rigorosos no tamanho do repositório. E, como já mencionado, o arquivo podfile.lock - enquanto a versão controlada fornece um bom histórico de suas versões do Pod.

No final do dia, se você tiver um prazo final apertado, um orçamento apertado, o tempo é essencial - precisamos ser o mais engenhosos possível e não perder tempo com ideologias estritas, e usar um conjunto de ferramentas para trabalhar em conjunto - tornar nossa vida mais fácil e mais eficiente.

No final, depende de você a abordagem adotada.

Isto é o que a equipe Cocoapods pensa sobre isso:

A decisão de verificar ou não a pasta Pods depende de você, pois os fluxos de trabalho variam de projeto para projeto. Recomendamos que você mantenha o diretório Pods sob controle de origem e não o adicione ao seu .gitignore. Mas, finalmente, essa decisão é com você.

Pessoalmente, gostaria de manter os Pods fora, como node_modules se eu estivesse usando o Node ou bower_components se estivesse usando o Bower . Isso se aplica a quase todos os Dependency Manager existentes, e também é a filosofia por trás dos submódulos git .

No entanto, às vezes você pode querer ter certeza do estado da arte de uma certa dependência; dessa maneira, você é portador da própria dependência do projeto. Obviamente, existem várias desvantagens que se aplicam se você fizer isso, mas as preocupações não se aplicam apenas aos Cocoapods, elas se aplicam a qualquer Dependency Manager existente.

Abaixo, há uma boa lista de prós / contras da equipe Cocoapods e o texto completo da citação mencionada anteriormente.

Equipe Cocoapods: Devo verificar o diretório Pods no controle de origem?

Depende, pessoalmente:

Por que os pods devem fazer parte do repositório (sob controle de origem) e não devem ser ignorados

• A fonte é idêntica
• Você pode construí-lo imediatamente como está (mesmo sem os cocoapods)
• Mesmo que um pod seja excluído, ainda temos sua cópia (Sim, isso pode acontecer e ocorreu. Em um projeto antigo em que você deseja apenas uma pequena alteração, seria necessário implementar uma nova biblioteca para poder construir).
• pods.xcodeprojas configurações também fazem parte do controle de origem. Isso significa, por exemplo, se você possui o projeto swift 4, mas alguns pods precisam estar swift 3.2porque ainda não foram atualizados, essas configurações serão salvas. Caso contrário, quem clonou o repositório acabaria com erros.
• Você sempre pode excluir os pods do projeto e executar pod install, o contrário não pode ser feito.
• Até os autores dos Cocoapods recomendam.

Alguns contras: repositório maior, diferenças confusas (principalmente para membros da equipe), potencialmente mais conflitos.

Para mim, a maior preocupação é proteger sua fonte no futuro. Se você planeja que seu projeto dure por um tempo e o CocoaPods desapareça ou a fonte de um dos pods diminua, você estará completamente sem sorte se tentar criar novas informações a partir de um arquivo.

Isso pode ser mitigado com arquivamentos periódicos de fontes completas.

Verifique nos Pods.

Eu acho que isso deve ser um princípio de desenvolvimento de software

• Todas as construções devem ser reproduzíveis
• A única maneira de garantir que reproduções sejam reproduzíveis é estar no controle de todas as dependências; verificar todas as dependências é, portanto, obrigatório.
• Um novo desenvolvedor, começando do zero, poderá verificar seu projeto e começar a trabalhar.

Por quê?

CocoaPods ou quaisquer outras bibliotecas externas podem mudar, o que pode quebrar as coisas. Ou eles podem se mover ou ser renomeados ou completamente removidos. Você não pode confiar na internet para guardar coisas para você. Seu laptop pode ter morrido e há um erro crítico na produção que precisa ser corrigido. O desenvolvedor principal pode ser atropelado por um ônibus e seu substituto deve ser iniciado com pressa. E gostaria que o último fosse um exemplo teórico, mas realmente aconteceu em uma startup em que eu estava. DESCANSE EM PAZ.

Agora, realisticamente, você não pode realmente verificar TODAS as dependências. Você não pode fazer check-in de uma imagem da máquina que você usou para criar builds; você não pode verificar a versão exata do compilador. E assim por diante. Existem limites realistas. Mas verifique tudo o que puder - não fazer isso apenas torna sua vida mais difícil. E nós não queremos isso.

Palavra final: os pods não são artefatos de construção. Artefatos de construção são o que é gerado a partir de suas construções. Sua compilação usa Pods, não os gera. Não sei ao certo por que isso precisa ser debatido.

Prós de não fazer check-in Pods/no controle de versão (em ordem subjetiva de importância):

1. Muito mais fácil mesclar confirmações e revisão de código diffs. A mesclagem é uma fonte comum de problemas em uma base de código, e isso permite que você se concentre apenas nas coisas pertinentes.
2. É impossível para algum colaborador aleatório editar as próprias dependências e verificar as alterações, o que elas nunca deveriam fazer (e novamente seria difícil identificar se a diferença é enorme). A edição de dependências é uma prática muito ruim, porque um futuro pod installpode ocultar as alterações.
3. Discrepâncias entre o diretório Podfilee o Pods/diretório são encontradas mais rapidamente entre os colegas de equipe. Se você fizer o check-in Pods/e, por exemplo, atualizar uma versão no Podfile, mas esquecer de executar pod installou fazer o check-in das alterações Pods/, será muito mais difícil perceber a origem da discrepância. Se Pods/não houver check-in, você sempre precisará executar de pod installqualquer maneira.
4. Tamanho menor do repositório. Ter uma pegada de bytes menor é bom, mas isso não importa muito no grande esquema. Mais importante: ter mais coisas no repositório também aumenta sua carga cognitiva. Não há razão para ter coisas no repositório que você não deveria estar olhando. Consulte a documentação (a abstração) para saber como algo funciona, não no código (a implementação).
5. Mais fácil discernir quanto alguém contribui (uma vez que suas linhas de código contribuíram não incluirão dependências que não foram escritas)
6. JARarquivos .venv/(ambientes virtuais) e node_modules/nunca são incluídos no controle de versão. Se fôssemos completamente independentes da questão, não fazer o check-in Podsseria o padrão com base no precedente.

Contras de não fazer check-inPods/

1. Você deve correr pod install ao alternar ramificações ou reverter confirmações.
2. Você não pode executar um projeto apenas clonando o repositório. Você deve instalar a ferramenta pod e executar pod install.
3. Você deve ter uma conexão com a Internet para executar pod install, e a fonte dos pods deve estar disponível.
4. Se o proprietário de uma dependência remover o pacote, você estará com problemas.

Em resumo, não incluir o Podsdiretório é um guardrail contra mais práticas ruins. A inclusão do Podsdiretório facilita a execução do projeto. Eu prefiro o primeiro do que o último. Você não precisará consultar cada nova pessoa em um projeto sobre "o que não fazer" se não houver possibilidade de cometer certos erros em primeiro lugar. Também gosto da ideia de ter um controle de versão separado, para o Podsqual alivia os Contras.

Em teoria, você deve verificar no diretório Pods. Na prática, nem sempre isso vai funcionar. Muitos pods excedem bem o limite de tamanho dos arquivos do github; portanto, se você estiver usando o github, terá problemas ao verificar o diretório Pods.

TL; DR: quando você controla a Pods/pasta, é mais fácil escolher o projeto. Quando você não o acompanha, é mais fácil melhorar quando você trabalha em equipe.

Embora a organização Cocoapods nos incentive a rastrear o Pods/diretório, eles dizem que cabe aos desenvolvedores decidir se devem ou não fazê-lo com base nesses prós e contras:  http://guides.cocoapods.org/using/using-cocoapods.html # should-i-check-the-pods-directory-in-source-control

Pessoalmente, geralmente acompanho a Pods/pasta apenas para projetos nos quais não trabalharei mais por um tempo. Dessa forma, qualquer desenvolvedor pode buscá-lo rapidamente e continuar o trabalho usando a versão adequada dos cocoapods.

Por outro lado, acho que o histórico de consolidação fica mais limpo e é mais fácil mesclar o código e revisar o código de outra pessoa quando você não está rastreando a Pods/pasta. Normalmente, defino a versão da biblioteca cocoapod quando a instalo para garantir que alguém possa instalar o projeto usando as mesmas versões que eu.

Além disso, quando o Pods/diretório está sendo rastreado, todos os desenvolvedores precisam usar a mesma versão do Cocoapods para impedir que ele altere dezenas de arquivos toda vez que executamos pod installpara adicionar / remover um pod.

Conclusão : quando você acompanha a Pods/pasta, é mais fácil escolher o projeto. Quando você não o acompanha, é mais fácil melhorar.

Parece que uma boa maneira de estruturar isso seria ter o diretório "Pods" como um submódulo git / projeto separado, eis o porquê.

• Ter pods no repositório do projeto, ao trabalhar com vários desenvolvedores, pode causar diferenças MUITO GRANDES nas solicitações pull, onde é quase impossível ver o trabalho real que foi alterado pelas pessoas (pense em várias centenas a milhares de arquivos alterados para bibliotecas e apenas um poucos mudaram no projeto real).

• Vejo a questão de não comprometer nada com o git, como a pessoa que possui a biblioteca pode derrubá-la a qualquer momento e você é essencialmente SOL, isso também resolve isso.

A decisão de verificar ou não a pasta Pods depende de você, pois os fluxos de trabalho variam de projeto para projeto. Recomendamos que você mantenha o diretório Pods sob controle de origem e não o adicione ao seu .gitignore. Mas, finalmente, esta decisão é sua:

Benefícios da verificação no diretório Pods

1. Após a clonagem do repositório, o projeto pode ser executado e executado imediatamente, mesmo sem os CocoaPods instalados na máquina. Não é necessário executar a instalação do pod e nenhuma conexão com a Internet é necessária.
2. Os artefatos do Pod (código / bibliotecas) estão sempre disponíveis, mesmo se a fonte de um Pod (por exemplo, GitHub) fosse desativada.
3. É garantido que os artefatos do Pod sejam idênticos aos da instalação original após a clonagem do repositório.

Benefícios de ignorar o diretório Pods

1. O repositório de controle de origem será menor e ocupará menos espaço. Desde que as fontes (por exemplo, GitHub) de todos os Pods estejam disponíveis, o CocoaPods geralmente pode recriar a mesma instalação (tecnicamente não há garantia de que a instalação do pod em execução irá buscar e recriar artefatos idênticos quando não estiver usando um SHA de confirmação no Podfile Isso é especialmente verdade ao usar arquivos zip no Podfile.)
2. Não haverá conflitos para lidar ao executar operações de controle de origem, como mesclar ramificações com diferentes versões do Pod. Quer você verifique ou não o diretório Pods, o Podfile e o Podfile.lock devem sempre ser mantidos sob controle de versão.