Was passiert in Ihrem .gitignore, wenn Sie CocoaPods verwenden?

Ich versuche, mir meine Hülsen-Verzeichnis. Ich bin nicht einverstanden, dass die Hülsen-Verzeichnis ist ein build-Artefakt. In der Tat würde ich sagen, dass es definitiv nicht. Es ist Teil Ihrer Anwendung Quelle: es wird nicht bauen, ohne es!

Es ist einfacher, zu denken, CocoaPods als ein Entwickler-tool, sondern als ein build-tool. Sie nicht erstellen Sie Ihr Projekt, es ist einfach zu Klonen und installiert Ihre Abhängigkeiten für Sie. Es sollte nicht notwendig sein, CocoaPods installiert zu werden, können Sie einfach erstellen Sie Ihr Projekt.

Durch CocoaPods eine Abhängigkeit von Ihren bauen, die Sie jetzt brauchen, um sicherzustellen, es ist überall verfügbar, müssen Sie möglicherweise erstellen Sie Ihr Projekt...ein team admin braucht es, Ihre CI-server benötigt. Sie sollten in der Regel immer in der Lage, Klonen Sie Ihre Quell-repository und build ohne weitere Anstrengung.

Nicht Begehen, Ihre Hülsen-Verzeichnis erstellt auch eine riesige Kopfschmerzen sein, wenn Sie wechseln Häufig den Zweigen. Nun müssen Sie zum ausführen der pod zu installieren, jedes mal, wenn Sie wechseln Zweige, um sicherzustellen, dass Ihre Abhängigkeiten korrekt sind. Dies ist weniger Aufwand als Ihre Abhängigkeiten zu stabilisieren, aber früh in einem Projekt dies ist eine massive Zeit sinken.

Also, was soll ich ignorieren? Nichts. Podfile, die lock-Datei und die Hülsen Verzeichnis alle verpflichtet. Vertrauen Sie mir, es spart Ihnen eine Menge ärger. Was sind die Nachteile? Eine etwas größere repo? Nicht das Ende der Welt.

InformationsquelleAutor der Antwort Luke Redpath

Normalerweise arbeite ich auf app ' s von Kunden. In diesem Fall füge ich die Hülsen Verzeichnis der repo als auch, um sicherzustellen, dass zu jeder Zeit jeder Entwickler tun könnte, die Kasse und erstellen und ausführen.

Wenn es eine app von unserer eigenen würde, würde ich wahrscheinlich ausschließen, dass der Hülsen-Verzeichnis, bis ich nicht auf Sie für eine Weile.

Eigentlich, ich muss feststellen, dass ich möglicherweise nicht die beste person, Ihre Frage zu beantworten, im Vergleich zu Ansichten der Reine Benutzer 🙂 ich werde tweet über diese Frage aus https://twitter.com/CocoaPodsOrg.

InformationsquelleAutor der Antwort alloy

Ich check-in alles. (Pods/ und Podfile.lock.)

Ich möchte in der Lage sein zu Klonen Sie das repository und wissen, dass alles nur funktionieren, wie es das Letzte mal Tat ich benutzte die app.

Ich würde eher Verkäufer, die Dinge, als die Gefahr ein, dass unterschiedliche Ergebnisse verursacht werden könnten, indem eine andere version des gem, oder jemand, die Geschichte umzuschreiben, in der die Pod-repository, etc.

InformationsquelleAutor der Antwort funroll

Ich bin in das Lager der Entwickler, die keine check-in-Bibliotheken, vorausgesetzt, wir haben eine gute Kopie in einem anderen Ort. So, in meinem .gitignore ich die folgenden Zeilen enthalten spezifische CocoaPods:

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

Dann bin ich sicher, dass wir eine Kopie der Bibliotheken an einem sicheren Ort. Eher als (mis-)einen Projekt-code-repository zur Speicherung der Abhängigkeiten (kompiliert oder nicht) ich denke, der beste Weg, dies zu tun ist, um Archiv baut. Wenn Sie ein CI-server für Ihr baut (wie Jenkins) können Sie dauerhaft archivieren alle builds, die Ihnen wichtig sind. Wenn man alle Ihre Produktions-builds in Ihrem lokalen Xcode, machen Sie eine Gewohnheit, die ein Archiv Ihres Projekts für alle builds, die Sie benötigen, um zu halten. So etwas wie:
1. Produkt --> Archiv

1. Verteilen... Einreichen, um die iOS-App-Store /Save for Enterprise or Ad hoc Deployment /was haben Sie

2. Zeigen Sie Ihre Projekt-Ordner im Finder

3. Recht-klicken Sie und Komprimieren "WhateverProject"

Dieser bietet eine as-built-Bild des gesamten Projekts, einschließlich der kompletten Projekt-und workspace-Einstellungen, die verwendet wird, um die app als auch als binary-Distributionen (wie Sparkle, proprietären SDKs wie TestFlight, etc.) ob oder nicht Sie verwenden CocoaPods.

Update: ich habe meine Meinung geändert, auf diese, und jetzt tun, Begehen die Podfile.lock zur Quellcodeverwaltung. Aber ich glaube immer noch, dass die Schoten selbst sind build-Artefakte und verwaltet werden sollten als solche, die außerhalb der source-control, die durch eine andere Methode, wie Sie Ihre CI-server oder eine Archivierung, wie ich oben beschreiben.

InformationsquelleAutor der Antwort Alex Nauda

Ich muss sagen, ich bin ein fan der Begehung von Hülsen auf das repository. Nach einem link bereits erwähnt wird Ihnen ein guter .gitignore-Datei zu erhalten, bis Sie Ihre Xcode-Projekte für iOS zu ermöglichen Hülsen, sondern auch für Sie ganz einfach ausschließen, wenn Sie so wollen: https://github.com/github/gitignore/blob/master/Objective-C.gitignore

Meine Argumentation als fan hinzufügen von Hülsen, um das repository ist ein wesentlicher Grund, die niemand scheint zu sein, Kommissionierung bis auf das, was passiert, wenn eine Bibliothek, die unser Projekt ist so abhängig ist, plötzlich aus dem web entfernt?

• Vielleicht der host entscheidet, die Sie nicht mehr wollen, um Ihre GitHub
  Konto eröffnen, Was passiert, wenn die Bibliothek ist zu sagen, mehrere Jahre alt
  (wie, die älter als 5 Jahre zum Beispiel) es besteht ein hohes Risiko der
  Projekt möglicherweise nicht mehr verfügbar sein, an der Quelle
• Auch ein weiterer Punkt, was passiert, wenn der URL des repository
  änderungen? Können sagen, die person, die den Pod aus Ihrer GitHub
  Konto, beschließt, die stellen sich unter einem anderen handle -
  Ihre "Pods" sind die URLs zu brechen.
• Schließlich ein weiterer Punkt. Sagen wenn Sie ein Entwickler wie mich, die nicht viel
  codieren, wenn auf einem Flug zwischen den Ländern. Ich mache einen schnellen Zug auf
  die 'master' - branch, ein pod zu installieren auf diesen Zweig sitzend
  im Flughafen und haben mich für die kommenden 8 Stunden
  Flug. Ich bekomme 3 Stunden in meinem flight, und ich erkenne, dass ich wechseln zu müssen
  ein anderer Zweig.... 'DOH' - fehlt-Pod Informationen, die nur auf die 'master' - branch.

NB... bitte beachten Sie die 'master' - branch für die Entwicklung ist nur für die Beispiele, offensichtlich 'master' - branches in der Versionsverwaltung, sollte sauber gehalten werden und verlegbare/baubare jederzeit

Ich denke, aus diesen Momentaufnahmen im code-repositories sind sicherlich besser, als streng über die repository-Größe. Und wie bereits erwähnt, wird das podfile.lock-Datei - während-version gesteuert wird, geben Sie eine gute Geschichte der Pod-Versionen.

Am Ende des Tages, wenn Sie haben einen dringenden Termin, mit einem knappen budget, die Zeit drängt - wir müssen so einfallsreich wie möglich und verschwenden keine Zeit auf strenge Ideologien, und statt Gurt eine Reihe von tools zusammen zu arbeiten - zu machen unser Leben einfacher, effizienter.

InformationsquelleAutor der Antwort leewilson86

Es hängt davon ab, persönlich:

Warum pods sollten Teil des repo (unter source control) und sollte nicht ignoriert werden

• Die Quelle ist identisch
• Können Sie bauen es sofort, da ist (auch ohne die cocoapods)
• Auch wenn ein pod ist gelöscht, wir haben noch seine Kopie (ja, das kann passieren, und es Tat. In einem alten Projekt, wo Sie wollen nur eine kleine änderung, die Sie brauchen würde, um die Implementierung einer neuen Bibliothek können sogar bauen).
• pods.xcodeproj Einstellungen sind Teil der Quelle Kontrolle. Dies bedeutet z.B., wenn Sie das Projekt in swift 4aber einige Schoten müssen in swift 3.2 weil Sie noch nicht aktualisiert haben, werden diese Einstellungen gespeichert. Ansonsten derjenige, der die repo geklont würde am Ende mit Fehler.
• Können Sie immer zu löschen Hülsen aus dem Projekt, und führen Sie pod installdas Gegenteil kann nicht getan werden.
• Auch die Autoren der Cocoapods empfehlen.

Einige Nachteile: größere repository, verwirrend diffs (vor allem für team-Mitglieder), die möglicherweise mehr Konflikte.

InformationsquelleAutor der Antwort Jakub Truhlář

Check-in die Hülsen.

Ich denke, das sollte ein Grundsatz der software-Entwicklung

• Alle builds müssen reproduzierbar sein
• Der einzige Weg, um sicherzustellen builds sind
  reproduzierbar ist die Kontrolle aller Abhängigkeiten; die Prüfung in allen
  Abhängigkeiten ist daher ein muss.
• Einen neuen Entwickler von Grund auf neu beginnen müssen in der Lage sein zu überprüfen, Ihre Projekt-und anfangen zu arbeiten.

Warum?

CocoaPods oder einem anderen externen Bibliotheken ändern könnte, die möglicherweise die Dinge brechen. Oder Sie möglicherweise verschoben oder umbenannt werden, oder werden ganz entfernt. Sie können nicht auf das internet verlassen zum speichern von Sachen für Sie. Dein laptop hätte sterben können und es ist ein Kritischer Fehler in der Produktion behoben werden muss. Der Haupt-Entwickler bekommen von einem bus angefahren und sein Ersatz hat zu starten, bis Sie es eilig haben. Und ich Wünsche mir, dass Letzte war ein theoretisches Beispiel, aber es ist tatsächlich passiert bei einem startup war ich mit. RIP.

Nun, realistisch gesehen, kann man nicht wirklich überprüfen in ALLEN Abhängigkeiten. Sie können nicht überprüfen, in einem Bild der Maschine, die Sie verwendet, um zu erstellen, baut; man kann nicht check-in die genaue version des Compilers. Und so weiter. Es sind realistische Grenzen. Aber check-in alles, was Sie können - nicht tun, so einfach macht Ihr Leben härter. Und das wollen wir nicht.

Letzte Wort: die Kapseln sind nicht build-Artefakte. Build-Artefakte sind das, was generiert wird von Ihrem baut. Ihr build verwendet, Hülsen, nicht zu generieren. Ich bin mir auch nicht sicher, warum dies hat, über die diskutiert werden.

InformationsquelleAutor der Antwort n13

Ob oder nicht Sie schauen in Ihre Pods-Ordner ist bis zu Ihnen, wie Sie workflows von Projekt zu Projekt variieren. Wir empfehlen, dass Sie halten die Hülsen Verzeichnis unter Versionskontrolle, und nicht fügen Sie es zu Ihrem .gitignore. Aber letztlich ist diese Entscheidung bis zu Ihnen:

Vorteile der Prüfung in den Hülsen Verzeichnis

1. Nach dem Klonen die repo, kann das Projekt sofort erstellen und ausführen, auch ohne CocoaPods installiert auf der Maschine. Es gibt keine Notwendigkeit ausführen pod installieren, und keine Internet-Verbindung notwendig ist.
2. Der Pod Artefakte (code/libraries) stets verfügbar sind, selbst wenn die Quelle von einem Pod (z.B. GitHub) wurden zu gehen.
3. Der Pod Artefakte sind garantiert identisch mit denen in der ursprünglichen installation nach dem Klonen die repo.

Vorteile zu ignorieren, die Schoten Verzeichnis

1. Die source-control-repo kleiner sind und weniger Platz einnehmen.
   Solange die Quellen (z.B. GitHub) für alle Hülsen sind verfügbar, CocoaPods ist in der Regel in der Lage, neu zu erstellen die gleiche installation.(Technisch gesehen gibt es keine Garantie, dass die Ausführung pod installieren zu Holen und neu zu erstellen, identische Artefakte, wenn Sie nicht über ein commit-SHA im Podfile. Dies gilt insbesondere bei der Verwendung von zip-Dateien in das Podfile.)
2. Es werden keine Konflikte zu bewältigen bei der Durchführung von source-control-Operationen, wie das Zusammenführen von Zweigen mit unterschiedlichen Pod-Versionen.
   Ob oder nicht Sie schauen in den Hülsen-Verzeichnis, das Podfile und Podfile.sperren sollten immer gehalten werden, die unter version control.

InformationsquelleAutor der Antwort Sourabh Mahna