Sto sviluppando iOS da un paio di mesi e ho appena appreso della promettente libreria CocoaPods per la gestione delle dipendenze.

L'ho provato su un progetto personale: ho aggiunto una dipendenza a Kiwi al mio Podfile, ho corso pod install CocoaPodsTest.xcodeproje voilà , ha funzionato benissimo.

L'unica cosa che mi chiedo è: cosa devo controllare e cosa ignoro per il controllo della versione? Sembra ovvio che voglio controllare il Podfile stesso, e probabilmente anche il file .xcworkspace; ma ignoro la directory Pods /? Ci sono altri file che verranno generati lungo la strada (quando aggiungo altre dipendenze) che dovrei aggiungere anche al mio .gitignore?

Personalmente non controllo nella directory e nei contenuti di Pods. Non posso dire di aver trascorso lunghe età considerando le implicazioni, ma il mio ragionamento è qualcosa del tipo:

Il Podfile si riferisce a un tag specifico o al commit di ogni dipendenza in modo che i Pod stessi possano essere generati dal podfile, ergo sono più simili a un prodotto di build intermedio che a una fonte e, quindi, non hanno bisogno del controllo della versione nel mio progetto.

Commetto la mia directory Pods. Non sono d'accordo sul fatto che la directory Pods sia un artefatto build. In effetti direi che sicuramente non lo è. Fa parte del tuo sorgente di applicazione: non si costruirà senza di essa!

È più facile pensare a CocoaPods come uno strumento di sviluppo piuttosto che uno strumento di creazione. Non costruisce il tuo progetto, semplicemente clona e installa le tue dipendenze per te. Non dovrebbe essere necessario avere CocoaPods installato per poter semplicemente costruire il tuo progetto.

Rendendo CocoaPods una dipendenza della tua build, ora devi assicurarti che sia disponibile ovunque tu possa aver bisogno per costruire il tuo progetto ... un amministratore del team ne ha bisogno, il tuo server CI ne ha bisogno. Dovresti, di regola, essere sempre in grado di clonare il tuo repository di origine e creare senza ulteriori sforzi.

Non eseguire il commit della directory Pods crea anche un forte mal di testa se si cambia frequentemente i rami. Ora devi eseguire l'installazione del pod ogni volta che cambi ramo per assicurarti che le tue dipendenze siano corrette. Questo potrebbe essere meno fastidi man mano che le tue dipendenze si stabilizzano, ma all'inizio di un progetto questo è un enorme spreco di tempo.

Quindi, cosa ignoro? Niente. Podfile, il file lock e la directory Pods vengono tutti impegnati. Fidati di me, ti farà risparmiare molta seccatura. Quali sono i contro? Un repo leggermente più grande? Non è la fine del mondo.

Consiglio di utilizzare Gitignore Objective-C di GitHub . Nel dettaglio, le migliori pratiche sono:

• La Podfile deve sempre essere sotto il controllo di origine.
• La Podfile.lock deve sempre essere sotto il controllo di origine.
• L'area di lavoro generata da CocoaPods dovrebbe essere mantenuta sotto il controllo del codice sorgente.
• Qualsiasi Pod a cui si fa riferimento con l' :pathopzione deve essere mantenuto sotto il controllo del codice sorgente.
• La ./Podscartella può essere mantenuta sotto il controllo del codice sorgente.

Per ulteriori informazioni è possibile consultare la guida ufficiale .

fonte: sono un membro del core team di CocoaPods, come @alloy

Sebbene la cartella Pods sia un artefatto di compilazione, ci sono motivi che potresti prendere in considerazione mentre decidi se tenerlo sotto il controllo del codice sorgente:

• CocoaPods non è un gestore di pacchetti, quindi la fonte originale della libreria potrebbe essere rimossa in futuro dall'autore.
• Se la cartella Pods è inclusa nel controllo del codice sorgente, non è necessario installare CocoaPods per eseguire il progetto poiché il checkout sarebbe sufficiente.
• CocoaPods è ancora in fase di elaborazione e ci sono opzioni che non portano sempre allo stesso risultato (ad esempio :headle :gitopzioni e al momento non utilizzano i commit memorizzati nella Podfile.lock).
• Ci sono meno punti di errore se si può riprendere a lavorare su un progetto dopo un periodo medio / lungo.

.gitignore file

Nessuna risposta in realtà offre un .gitignore, quindi ecco due gusti.

Verifica nella directory Pods ( Vantaggi )

Xcode / iOS friendly git ignora, saltando i file di sistema di Mac OS, Xcode, build, altri repository e backup.

.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/

Ignorare la directory Pods ( Vantaggi )

.gitignore: (aggiungi all'elenco precedente)

# Cocoapods
Pods/

Indipendentemente dal fatto che tu controlli nella directory Pods, Podfile e Podfile.lock devono sempre essere controllati dalla versione.

In caso Podscontrario, è Podfilenecessario richiedere numeri di versione espliciti per ciascun Cocoapod. Discussione su Cocoapods.org qui .

In genere lavoro sulle app dei clienti. In tal caso aggiungo anche la directory Pods al repository, per garantire che in qualsiasi momento qualsiasi sviluppatore possa effettuare un checkout, compilare ed eseguire.

Se fosse una nostra app, probabilmente escluderei la directory Pods fino a quando non ci lavorerò per un po '.

In realtà, devo concludere che potrei non essere la persona migliore per rispondere alla tua domanda, rispetto alle opinioni di utenti puri :) Twitterò su questa domanda da https://twitter.com/CocoaPodsOrg .

Controllo tutto. ( Pods/e Podfile.lock.)

Voglio essere in grado di clonare il repository e sapere che tutto funzionerà come ha fatto l'ultima volta che ho usato l'app.

Preferirei vendere le cose piuttosto che rischiare di avere risultati diversi che potrebbero essere causati da una versione diversa della gemma o da qualcuno che riscriva la cronologia nel repository del Pod, ecc.

La risposta per questo è data direttamente nei documenti Cocoapod. Puoi guardare " http://guides.cocoapods.org/using/using-cocoapods.html#should-i-ignore-the-pods-directory-in-source-control "

A prescindere dal fatto che tu controlli nella cartella Pods, dipende dal fatto che i flussi di lavoro variano da progetto a progetto. Ti consigliamo di mantenere la directory Pods sotto il controllo del codice sorgente e di non aggiungerla al tuo .gitignore. Ma alla fine questa decisione spetta a te:

Vantaggi del controllo nella directory Pods

• Dopo aver clonato il repository, il progetto può immediatamente essere creato ed eseguito, anche senza CocoaPods installato sulla macchina. Non è necessario eseguire l'installazione del pod e non è necessaria alcuna connessione a Internet.
• Gli artefatti del Pod (codice / librerie) sono sempre disponibili, anche se la fonte di un Pod (es. GitHub) dovesse scendere.
• Gli artefatti Pod sono garantiti identici a quelli nell'installazione originale dopo la clonazione del repository.

Vantaggi dell'ignorare la directory Pods

• Il repository di controllo del codice sorgente sarà più piccolo e occuperà meno spazio.

• Finché sono disponibili le fonti (ad es. GitHub) per tutti i pod, CocoaPods è generalmente in grado di ricreare la stessa installazione. (Tecnicamente non esiste alcuna garanzia che l'esecuzione dell'installazione pod recupererà e creerà artefatti identici quando non si utilizza un commit SHA nel Podfile. Ciò è particolarmente vero quando si utilizzano file zip nel Podfile.)

• Non ci saranno conflitti da affrontare quando si eseguono operazioni di controllo del codice sorgente, come l'unione di filiali con diverse versioni di Pod.

Indipendentemente dal fatto che tu controlli nella directory Pods, Podfile e Podfile.lock devono sempre essere controllati dalla versione.

Sono nel campo degli sviluppatori che non controllano le librerie, supponendo che ne abbiamo una buona copia disponibile in un'altra posizione. Quindi, nel mio .gitignore includo le seguenti righe specifiche per CocoaPods:

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

Quindi mi assicuro che abbiamo una copia delle librerie in un luogo sicuro. Invece di (mis-) utilizzare un repository di codice di un progetto per archiviare dipendenze (compilate o meno), penso che il modo migliore per farlo sia quello di archiviare le build. Se usi un server CI per le tue build (come Jenkins) puoi archiviare in modo permanente tutte le build importanti per te. Se esegui tutte le build di produzione nel tuo Xcode locale, prendi l'abitudine di prendere un archivio del tuo progetto per tutte le build che devi conservare. Qualcosa come: 1. Prodotto -> Archivio

1. Distribuisci ... Invia all'App Store iOS / Salva per Enterprise o Distribuzione ad hoc / Che cosa hai

2. Rivela la cartella del tuo progetto nel Finder

3. Fare clic destro e comprimere "Qualunque sia il progetto"

Ciò fornisce un'immagine as-built dell'intero progetto, comprese le impostazioni complete del progetto e dell'area di lavoro utilizzate per creare l'app e le distribuzioni binarie (come Sparkle, SDK proprietari come TestFlight, ecc.) Indipendentemente dal fatto che utilizzino o meno CocoaPods.

Aggiornamento: ho cambiato idea su questo e ora commetto il Podfile.lockcontrollo del codice sorgente. Tuttavia, credo ancora che i pod stessi siano artefatti da costruire e dovrebbero essere gestiti come tali al di fuori del controllo del codice sorgente, attraverso un altro metodo come il tuo server CI o un processo di archiviazione come ho descritto sopra.

Preferisco eseguire il commit della Podsdirectory insieme Podfilee Podfile.lockassicurarsi che chiunque nel mio team possa controllare la fonte in qualsiasi momento e che non debbano preoccuparsi di nulla o fare cose aggiuntive per farlo funzionare.

Ciò aiuta anche in uno scenario in cui è stato corretto un bug all'interno di uno dei pod o modificato un comportamento in base alle proprie esigenze, ma queste modifiche non saranno disponibili su altre macchine se non vengono commesse.

E per ignorare le directory non necessarie:

xcuserdata/

Devo dire che sono un fan del commit dei Pod nel repository. Seguire un link già menzionato ti darà un buon file .gitignore per ottenere i tuoi progetti Xcode per iOS per consentire Pods ma anche per escluderli facilmente se lo desideri: https://github.com/github/gitignore/ blob / master / Objective-C.gitignore

Il mio ragionamento per essere un fan dell'aggiunta di Pod al repository è per una ragione fondamentale su cui nessuno sembra prendere in considerazione, cosa succede se una libreria da cui il nostro progetto è così dipendente viene improvvisamente rimossa dal web?

• Forse l'host decide di non voler più tenere aperto l'account GitHub Cosa succede se la biblioteca dice che ha diversi anni (come ad esempio più di 5 anni) c'è un rischio elevato che il progetto potrebbe non essere più disponibile alla fonte
• Inoltre, cosa succede se l'URL del repository cambia? Diciamo che la persona che serve il Pod dal proprio account GitHub, decide di rappresentarsi con un handle diverso: gli URL dei Pod si romperanno.
• Finalmente un altro punto. Dì se sei uno sviluppatore come me che fa molto codice durante un volo tra paesi. Faccio un rapido giro sul ramo "master", eseguo l'installazione di un pod su quel ramo, mentre sono seduto in aeroporto e mi preparo per il prossimo volo di 8 ore. Ho 3 ore di volo e mi rendo conto che devo passare a un'altra filiale ... "DOH" - mancano le informazioni sul Pod che sono disponibili solo sulla filiale "principale".

NB ... si prega di notare che il ramo "master" per lo sviluppo è solo per esempio, ovviamente i rami "master" nei sistemi di controllo della versione, devono essere mantenuti puliti e implementabili / costruibili in qualsiasi momento

Penso che da questi, le istantanee nei repository di codice siano sicuramente meglio che essere rigorose sulla dimensione del repository. E come già accennato, il file podfile.lock - mentre la versione controllata ti darà una buona cronologia delle tue versioni Pod.

Alla fine della giornata, se hai una scadenza pressante, un budget limitato, il tempo è essenziale - dobbiamo essere il più intraprendenti possibile e non perdere tempo con ideologie rigorose, e invece sfruttare una serie di strumenti per lavorare insieme - per rendere la nostra vita più semplice, più efficiente.

Alla fine dipende da te l'approccio che segui.

Ecco cosa ne pensa il team Cocoapods:

A prescindere dal fatto che tu controlli nella cartella Pods, dipende dal fatto che i flussi di lavoro variano da progetto a progetto. Ti consigliamo di mantenere la directory Pods sotto il controllo del codice sorgente e di non aggiungerla al tuo .gitignore. Ma alla fine questa decisione dipende da te.

Personalmente vorrei tenere fuori Pod , come node_modules se stavo usando Node o bower_components se stavo usando Bower . Questo vale per quasi tutti i Dependency Manager là fuori, ed è anche la filosofia dietro i sottomoduli git .

Tuttavia a volte potresti voler essere veramente sicuro dello stato dell'arte di una certa dipendenza, in questo modo porti la dipendenza all'interno del tuo progetto. Naturalmente ci sono molti inconvenienti che si applicano se lo fai, ma le preoccupazioni non si applicano solo a Cocoapods, quelle si applicano a qualsiasi Dependency Manager là fuori.

Di seguito è riportato un buon elenco di pro / contro creato dal team Cocoapods e il testo completo della citazione menzionata in precedenza.

Team di Cocoapods: devo controllare la directory Pods nel controllo del codice sorgente?

Dipende, personalmente:

Perché i pod dovrebbero essere parte del repository (sotto il controllo del codice sorgente) e non dovrebbero essere ignorati

• La fonte è identica
• Puoi costruirlo subito com'è (anche senza i cocoapodi)
• Anche se un pod viene eliminato, ne abbiamo ancora una copia (Sì, questo può succedere e lo ha fatto. In un vecchio progetto in cui si desidera solo una piccola modifica, è necessario implementare una nuova libreria per poterlo persino costruire).
• pods.xcodeprojanche le impostazioni fanno parte del controllo del codice sorgente. Questo significa, ad esempio, se il progetto è presente swift 4, ma alcuni pod devono essere presenti swift 3.2perché non sono ancora stati aggiornati, queste impostazioni verranno salvate. Altrimenti chi clonava il repository finirebbe con errori.
• Puoi sempre eliminare i pod dal progetto ed eseguirlo pod install, non è possibile fare il contrario.
• Anche gli autori dei Cocoapod lo raccomandano.

Alcuni contro: repository più grande, differenze confuse (principalmente per i membri del team), potenzialmente più conflitti.

Per me, la più grande preoccupazione è la verifica futura della tua fonte. Se hai intenzione di far durare il tuo progetto per un po 'e CocoaPods scompare o la fonte di uno dei baccelli diminuisce, sei completamente sfortunato se provi a creare un nuovo archivio da un archivio.

Ciò potrebbe essere mitigato con periodici archivistici full source.

Controlla i pod.

Penso che questo dovrebbe essere un principio di sviluppo del software

• Tutte le build devono essere riproducibili
• L'unico modo per garantire che le build siano riproducibili è avere il controllo di tutte le dipendenze; il check-in in tutte le dipendenze è quindi un must.
• Un nuovo sviluppatore che inizia da zero deve essere in grado di controllare il tuo progetto e iniziare a lavorare.

Perché?

CocoaPods o qualsiasi altra libreria esterna potrebbe cambiare e ciò potrebbe spezzare le cose. Oppure potrebbero spostarsi, essere rinominati o essere rimossi del tutto. Non puoi fare affidamento su Internet per archiviare le cose per te. Il tuo laptop potrebbe essere morto e c'è un bug critico nella produzione che deve essere risolto. Lo sviluppatore principale potrebbe essere investito da un autobus e la sua sostituzione deve avviarsi in fretta. E vorrei che l'ultimo fosse un esempio teorico, ma in realtà è successo in una startup con cui ero. STRAPPARE.

Ora, realisticamente, non puoi davvero controllare TUTTE le dipendenze. Non è possibile archiviare un'immagine della macchina utilizzata per creare build; non è possibile verificare la versione esatta del compilatore. E così via. Ci sono limiti realistici. Ma controlla tutto quello che puoi - non farlo ti renderà la vita più difficile. E non lo vogliamo.

Parola finale: i pod non sono artefatti da costruire. Gli artefatti da build sono ciò che viene generato dalle tue build. La tua build utilizza Pod, non generarli. Non sono nemmeno sicuro del perché questo debba essere discusso.

Pro di non fare il check in Pods/al controllo versione (in ordine soggettivo di importanza):

1. È molto più facile unire i commit e rivedere le differenze del codice. L'unione è una fonte comune di problemi in una base di codice e ciò consente di concentrarsi solo sulle cose pertinenti.
2. È impossibile per alcuni contributori casuali modificare le dipendenze stesse e verificare le modifiche, cosa che non dovrebbero mai fare (e che sarebbe difficile identificare se il diff è massiccio). Modificare le dipendenze è una cattiva pratica perché un futuro pod installpotrebbe occludere i cambiamenti.
3. Le discrepanze tra la directory Podfilee la Pods/directory si trovano più rapidamente tra i compagni di squadra. Se effettui il check-in Pods/e, ad esempio, aggiorni una versione in Podfile, ma dimentichi di eseguire pod installo archiviare le modifiche a Pods/, avrai molto più difficoltà a notare l'origine della discrepanza. Se Pods/non è registrato, è sempre necessario eseguire pod installcomunque.
4. Dimensioni repo più piccole. Avere un ingombro di byte ridotto è bello, ma non importa molto nel grande schema. Ancora più importante: avere più cose nel repository aumenta anche il tuo carico cognitivo. Non c'è motivo di avere cose nel repository che non dovresti guardare. Fare riferimento alla documentazione (l'astrazione) per sapere come funziona qualcosa, non al codice (l'implementazione).
5. Più facile discernere quanto qualcuno contribuisce (dal momento che le sue righe di codice hanno contribuito non includeranno dipendenze che non hanno scritto)
6. JARfile .venv/(ambienti virtuali) e node_modules/non sono mai inclusi nel controllo versione. Se fossimo completamente agnostici riguardo alla domanda, non fare il check-in Podssarebbe l'impostazione predefinita in base al precedente.

Contro di non fare il check-inPods/

1. È necessario eseguire pod installquando si cambiano rami o si ripristinano i commit.
2. Non è possibile eseguire un progetto semplicemente clonando il repository. È necessario installare lo strumento pod, quindi eseguire pod install.
3. È necessario disporre di una connessione Internet per eseguire pod installe l'origine dei pod deve essere disponibile.
4. Se il proprietario di una dipendenza rimuove il proprio pacchetto, ci si trova in difficoltà.

In sintesi, non includere la Podsdirectory è una barriera contro altre cattive pratiche. L'inclusione della Podsdirectory semplifica l'esecuzione del progetto. Preferisco il primo al secondo. Non sarà necessario interrogare ogni nuova persona su un progetto su "cosa non fare" se non c'è la possibilità di fare alcuni errori in primo luogo. Mi piace anche l'idea di avere un controllo versione separato per il Podsquale allevia i contro.

In teoria, dovresti controllare nella directory Pods. In pratica, non funzionerà sempre. Molti pod superano di gran lunga il limite di dimensioni dei file github, quindi se si utilizza github si verificheranno problemi durante il controllo nella directory Pods.

TL; DR: quando si traccia la Pods/cartella, il progetto è più facile da raccogliere. Quando non lo segui, è più facile migliorare quando lavori in gruppo.

Sebbene l'organizzazione Cocoapods ci incoraggi a tracciare la Pods/directory, dicono che spetta agli sviluppatori decidere se farlo o meno in base a questi pro e contro:  http://guides.cocoapods.org/using/using-cocoapods.html # dovrei-i-check-the-pod-directory-in-source-controllo

Personalmente, di solito seguo la Pods/cartella solo per i progetti su cui non lavorerò più per un po '. In questo modo qualsiasi sviluppatore può prenderlo rapidamente e continuare il lavoro usando la versione corretta dei cocoapodi.

D'altra parte, penso che la cronologia del commit diventi più pulita ed è più facile unire il codice e rivedere il codice di un'altra persona quando non si tiene traccia della Pods/cartella. Di solito imposto la versione della libreria cocoapod quando la installo per essere sicuro che chiunque possa installare il progetto usando le stesse versioni di I.

Inoltre, quando la Pods/directory viene tracciata, tutti gli sviluppatori devono utilizzare la stessa versione di Cocoapods per impedire che cambi dozzine di file ogni volta che eseguiamo pod installper aggiungere / rimuovere un pod.

Conclusione : quando si traccia la Pods/cartella, il progetto è più facile da raccogliere. Quando non lo segui, è più facile migliorarlo.

Sembra un buon modo per strutturare questo sarebbe davvero avere la directory "Pods" come sottomodulo git / progetto separato, ecco perché.

• Avere pod nel repository del progetto, quando si lavora con diversi sviluppatori, può causare differenze MOLTO GRANDI nelle richieste pull in cui è quasi impossibile vedere il lavoro effettivo che è stato modificato dalle persone (si pensi che siano cambiate diverse centinaia e migliaia di file per le librerie, e solo un pochi sono cambiati nel progetto reale).

• Vedo il problema di non impegnare nulla a git, dal momento che la persona che possiede la libreria potrebbe eliminarla in qualsiasi momento e tu sei essenzialmente SOL, anche questo lo risolve.

A prescindere dal fatto che tu controlli nella cartella Pods, dipende dal fatto che i flussi di lavoro variano da progetto a progetto. Ti consigliamo di mantenere la directory Pods sotto il controllo del codice sorgente e di non aggiungerla al tuo .gitignore. Ma alla fine questa decisione spetta a te:

Vantaggi del controllo nella directory Pods

1. Dopo aver clonato il repository, il progetto può immediatamente essere creato ed eseguito, anche senza CocoaPods installato sulla macchina. Non è necessario eseguire l'installazione del pod e non è necessaria alcuna connessione a Internet.
2. Gli artefatti del Pod (codice / librerie) sono sempre disponibili, anche se la fonte di un Pod (es. GitHub) dovesse scendere.
3. Gli artefatti Pod sono garantiti identici a quelli nell'installazione originale dopo la clonazione del repository.

Vantaggi dell'ignorare la directory Pods

1. Il repository di controllo del codice sorgente sarà più piccolo e occuperà meno spazio. Finché sono disponibili le fonti (ad es. GitHub) per tutti i pod, CocoaPods è generalmente in grado di ricreare la stessa installazione (tecnicamente non esiste alcuna garanzia che l'esecuzione di un'installazione pod recuperi e ricrea artefatti identici quando non si utilizza un SHA di commit nel Podfile Questo è particolarmente vero quando si usano file zip nel Podfile.)
2. Non ci saranno conflitti da affrontare quando si eseguono operazioni di controllo del codice sorgente, come l'unione di filiali con diverse versioni di Pod. Indipendentemente dal fatto che tu controlli nella directory Pods, Podfile e Podfile.lock devono sempre essere controllati dalla versione.