Zajmuję się tworzeniem iOS od kilku miesięcy i właśnie poznałem obiecującą bibliotekę CocoaPods do zarządzania zależnościami.

Wypróbowałem to na osobistym projekcie: dodałem zależność od Kiwi do mojego Podfile, uruchomiłem pod install CocoaPodsTest.xcodeproji voila , działało świetnie.

Zastanawiam się tylko: co mam zameldować i co zignorować w przypadku kontroli wersji? Wydaje się oczywiste, że chcę sprawdzić sam plik Podfile i prawdopodobnie także plik .xcworkspace; ale czy mogę zignorować katalog Pods /? Czy są inne pliki, które zostaną wygenerowane w późniejszym czasie (kiedy dodam inne zależności), które powinienem również dodać do mojego .gitignore?

Osobiście nie sprawdzam w katalogu i zawartości Pods. Nie mogę powiedzieć, że spędziłem długie lata rozważając implikacje, ale moje rozumowanie jest takie:

Podfile odnosi się do określonego znacznika lub zatwierdzenia każdej zależności, więc same Pods mogą być generowane z pliku podfile, ergo są one bardziej jak produkt kompilacji pośredniej niż źródło, a zatem nie wymagają kontroli wersji w moim projekcie.

Zatwierdzam mój katalog Pods. Nie zgadzam się, że katalog Pods jest artefaktem kompilacji. W rzeczywistości powiedziałbym, że zdecydowanie nie jest. Jest to część twojego źródła aplikacji: bez niego nie da się zbudować!

Łatwiej jest myśleć o CocoaPods raczej jako narzędziu dla programistów niż narzędziu do budowania. Nie buduje twojego projektu, po prostu klonuje i instaluje dla ciebie twoje zależności. Zainstalowanie CocoaPods nie powinno być konieczne, aby móc po prostu zbudować projekt.

Uczyniając CocoaPods zależnością twojej kompilacji, musisz teraz upewnić się, że jest ona dostępna wszędzie tam, gdzie możesz potrzebować zbudować swój projekt ... potrzebuje tego administrator zespołu, a serwer CI tego potrzebuje. Z reguły powinieneś zawsze mieć możliwość klonowania repozytorium źródłowego i budowania bez żadnego dodatkowego wysiłku.

Nieprzestrzeganie katalogu Pods powoduje również ogromny ból głowy, jeśli często zmieniasz gałęzie. Teraz musisz uruchomić instalację pod za każdym razem, gdy zmieniasz oddziały, aby upewnić się, że twoje zależności są poprawne. Może to być mniej kłopotliwe, gdy twoje zależności ustabilizują się, ale na wczesnym etapie projektu jest to ogromne ograniczenie czasowe.

Co mam zignorować? Nic. Podfile, plik blokady i katalog Pods zostają zatwierdzone. Zaufaj mi, dzięki temu zaoszczędzisz wiele kłopotów. Jakie są minusy? Nieco większe repo? To nie koniec świata.

Polecam używać gitignore Objective-C w GitHub . W szczególności najlepsze praktyki to:

• Podfile Musi zawsze być pod kontrolą źródła.
• Podfile.lock Musi zawsze być pod kontrolą źródła.
• Obszar roboczy generowany przez CocoaPods powinien być pod kontrolą źródła.
• Każda kapsuła, do której odnosi się :pathopcja, powinna być pod kontrolą źródła.
• ./PodsFolderze może znajdować się pod kontrolą źródła.

Więcej informacji można znaleźć w oficjalnym przewodniku .

źródło: Jestem członkiem podstawowego zespołu CocoaPods, jak @alloy

Chociaż folder Pods jest artefaktem kompilacji, istnieją powody, które można wziąć pod uwagę, decydując się na zachowanie kontroli nad źródłem:

• CocoaPods nie jest menedżerem pakietów, więc oryginalne źródło biblioteki może zostać w przyszłości usunięte przez autora.
• Jeśli folder Pods jest objęty kontrolą źródła, nie trzeba instalować CocoaPods, aby uruchomić projekt, ponieważ wystarczyłoby kasy.
• CocoaPods jest nadal w toku i istnieją opcje, które nie zawsze prowadzą do tego samego rezultatu (na przykład :headi :gitopcje i obecnie nie używają zatwierdzeń zapisanych w Podfile.lock).
• Jest mniej punktów awaryjnych, jeśli możesz wznowić pracę nad projektem po średnio / długim czasie.

plik .gitignore

Żadna odpowiedź faktycznie nie oferuje .gitignore, więc oto dwa smaki.

Sprawdzanie w katalogu Pods ( Korzyści )

Git ignoruje przyjazne Xcode / iOS pomijanie plików systemowych Mac OS, Xcode, kompilacji, innych repozytoriów i kopii zapasowych.

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

Ignorowanie katalogu Pods ( Korzyści )

.gitignore: (dołącz do poprzedniej listy)

# Cocoapods
Pods/

Bez względu na to, czy sprawdzasz katalog Pods, Podfile i Podfile.lock powinny zawsze być pod kontrolą wersji.

Jeśli Podsnie są Podfileodprawieni, prawdopodobnie powinieneś poprosić o wyraźne numery wersji dla każdego Cocoapod. Dyskusja Cocoapods.org tutaj .

Generalnie pracuję nad aplikacjami klientów. W takim przypadku dodam również katalog Pods do repozytorium, aby upewnić się, że w dowolnym momencie każdy programista może dokonać kasy, skompilować i uruchomić.

Gdyby to była nasza aplikacja, prawdopodobnie wykluczyłbym katalog Pods, dopóki nie będę nad nim pracował przez jakiś czas.

Właściwie muszę stwierdzić, że być może nie jestem najlepszą osobą, aby odpowiedzieć na twoje pytanie, w przeciwieństwie do poglądów czystych użytkowników :) Będę tweetować na ten temat z https://twitter.com/CocoaPodsOrg .

Sprawdzam wszystko. ( Pods/i Podfile.lock.)

Chcę móc sklonować repozytorium i wiedzieć, że wszystko będzie działało tak, jak podczas ostatniego użycia aplikacji.

Wolę sprzedawać rzeczy, niż ryzykować różne wyniki, które mogą być spowodowane inną wersją klejnotu lub zapisaniem historii w repozytorium kapsuły itp.

Odpowiedź na to pytanie znajduje się bezpośrednio w dokumentach Cocoapod. Możesz spojrzeć na „ http://guides.cocoapods.org/using/using-cocoapods.html#should-i-ignore-the-pods-directory-in-source-control ”

Niezależnie od tego, czy zaznaczysz folder Pods, zależy od Ciebie, ponieważ przepływy pracy różnią się w zależności od projektu. Zalecamy trzymanie katalogu Pods pod kontrolą źródła i nie dodawanie go do swojego .gitignore. Ale ostatecznie decyzja należy do Ciebie:

Korzyści ze sprawdzania w katalogu Pods

• Po klonowaniu repozytorium projekt może natychmiast zbudować i uruchomić, nawet bez zainstalowania CocoaPods na maszynie. Nie ma potrzeby uruchamiania instalacji pod i nie jest wymagane połączenie z Internetem.
• Artefakty kapsuły (kod / biblioteki) są zawsze dostępne, nawet jeśli źródło kapsuły (np. GitHub) miałoby spaść.
• Po sklonowaniu repozytorium artefakty Kapsuły są identyczne z tymi w oryginalnej instalacji.

Korzyści z ignorowania katalogu Pods

• Repozytorium kontroli źródła będzie mniejsze i zajmie mniej miejsca.

• Tak długo, jak dostępne są źródła (np. GitHub) dla wszystkich kapsuł, CocoaPods jest w stanie odtworzyć tę samą instalację. (Technicznie nie ma gwarancji, że uruchomienie instalacji pod spowoduje pobranie i odtworzenie identycznych artefaktów, gdy nie używa się SHA zatwierdzenia w Podfile. Jest to szczególnie prawdziwe, gdy używa się plików zip w Podfile.)

• Podczas wykonywania operacji kontroli źródła nie będzie żadnych konfliktów, takich jak łączenie oddziałów z różnymi wersjami Pod.

Bez względu na to, czy sprawdzasz katalog Pods, Podfile i Podfile.lock powinny zawsze być pod kontrolą wersji.

Jestem w obozie programistów, którzy nie sprawdzają bibliotek, zakładając, że mamy dobrą kopię dostępną w innej lokalizacji. Tak więc w moim .gitignore dołączam następujące wiersze specyficzne dla CocoaPods:

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

Następnie upewniam się, że mamy kopię bibliotek w bezpiecznym miejscu. Zamiast (błędnie) używać repozytorium kodu projektu do przechowywania zależności (skompilowanych lub nie). Myślę, że najlepszym sposobem na to jest zarchiwizowanie kompilacji. Jeśli używasz serwera CI do swoich kompilacji (takich jak Jenkins), możesz trwale zarchiwizować wszystkie kompilacje, które są dla Ciebie ważne. Jeśli wykonujesz wszystkie kompilacje produkcyjne w lokalnym Xcode, nałóż na siebie archiwum swojego projektu dla wszystkich kompilacji, które musisz zachować. Coś w stylu: 1. Produkt -> Archiwum

1. Dystrybucja ... Prześlij do iOS App Store / Save for Enterprise lub Ad-hoc Deployment / what you

2. Ujawnij folder projektu w Finderze

3. Kliknij prawym przyciskiem myszy i skompresuj „WhthingProject”

Zapewnia to obraz powykonawczy całego projektu, w tym kompletnych ustawień projektu i obszaru roboczego używanych do budowy aplikacji, a także dystrybucji binarnych (takich jak Sparkle, zastrzeżone zestawy SDK, takie jak TestFlight itp.), Niezależnie od tego, czy używają CocoaPods.

Aktualizacja: Zmieniłem zdanie na ten temat i teraz dokonuję Podfile.lockkontroli źródła. Jednak nadal uważam, że same kapsułki są artefaktami kompilacji i powinny być zarządzane jako takie poza kontrolą źródła, za pomocą innej metody, takiej jak serwer CI lub proces archiwizacji, jak opisano powyżej.

Wolę zatwierdzić Podskatalog wraz z Podfilei Podfile.lockupewnić się, że każdy w moim zespole może sprawdzić źródło w dowolnym momencie i nie musi się o nic martwić ani robić dodatkowych rzeczy, aby działało.

Pomaga to również w scenariuszu, w którym naprawiono błąd w jednej z kapsuł lub zmodyfikowano niektóre zachowania zgodnie z potrzebami, ale zmiany te nie będą dostępne na innych komputerach, jeśli nie zostaną zatwierdzone.

I zignorować niepotrzebne katalogi:

xcuserdata/

Muszę powiedzieć, że jestem fanem angażowania kapsuł do repozytorium. Po kliknięciu już wspomnianego łącza otrzymasz dobry plik .gitignore, aby uzyskać dostęp do projektów Xcode na iOS, aby umożliwić korzystanie z Pod, ale także możesz je łatwo wykluczyć, jeśli chcesz: https://github.com/github/gitignore/ blob / master / Objective-C.gitignore

Moje powody, dla których jestem fanem dodawania kapsuł do repozytorium, są z jednego fundamentalnego powodu, którego nikt nie wydaje się zauważać. Co się stanie, jeśli biblioteka, od której tak zależy nasz projekt, zostanie nagle usunięta z sieci?

• Może gospodarz zdecyduje, że nie chce już utrzymywać konta GitHub otwartego. Co się stanie, jeśli biblioteka ma kilka lat (na przykład więcej niż 5 lat), istnieje duże ryzyko, że projekt może nie być już dostępny u źródła
• Kolejny punkt, co się stanie, jeśli zmieni się adres URL repozytorium? Powiedzmy, że osoba obsługująca kapsuła z konta GitHub decyduje się reprezentować siebie pod innym uchwytem - twoje URL-e kapsuły się zepsują.
• Wreszcie kolejny punkt. Powiedz, jeśli jesteś programistą takim jak ja, który dużo koduje podczas lotu między krajami. Szybko pociągam za gałąź „master”, instaluję pod nią gałąź, siedząc na lotnisku i przygotowuję się na najbliższy 8-godzinny lot. Dostaję 3 godziny lotu i zdaję sobie sprawę, że muszę się zmienić na inny oddział ... „DOH” - brak informacji o zasobach, które są dostępne tylko w oddziale „master”.

Uwaga: należy pamiętać, że gałąź „master” dla rozwoju jest tylko dla przykładów, oczywiście gałęzie „master” w systemach kontroli wersji powinny być utrzymywane w czystości i możliwe do wdrożenia / budowy w dowolnym momencie

Myślę, że z nich migawki w twoich repozytoriach kodu są z pewnością lepsze niż ścisłe rozmiar repozytorium. I jak już wspomniano, plik podfile.lock - podczas gdy wersja kontrolowana da ci dobrą historię twoich wersji Pod.

Na koniec dnia, jeśli masz pilny termin, napięty budżet, liczy się czas - musimy być tak zaradni, jak to możliwe i nie marnować czasu na surowe ideologie, a zamiast tego wykorzystać zestaw narzędzi do współpracy - aby nasze życie było łatwiejsze i bardziej wydajne.

Na końcu od Ciebie zależy, jakie podejmiesz podejście.

Tak myśli o tym zespół Cocoapods:

Niezależnie od tego, czy zaznaczysz folder Pods, zależy od Ciebie, ponieważ przepływy pracy różnią się w zależności od projektu. Zalecamy trzymanie katalogu Pods pod kontrolą źródła i nie dodawanie go do swojego .gitignore. Ale ostatecznie decyzja należy do ciebie.

Osobiście chciałbym trzymać Pods z dala, jako moduły_węzłów, gdybym używał Węzła lub bower_components, jeśli użyłem Bowera . Dotyczy to prawie każdego menedżera zależności i jest to również filozofia stojąca za podmodułami git .

Czasami jednak możesz chcieć być naprawdę pewny co do najnowszego stanu zależności, w ten sposób posiadasz zależność w swoim projekcie. Oczywiście, jeśli to zrobisz, istnieje kilka wad, ale obawy dotyczą nie tylko Cocoapods, ale dotyczą każdego menedżera zależności.

Poniżej znajduje się dobra lista zalet / wad stworzona przez zespół Cocoapods oraz pełny tekst cytatu wspomnianego wcześniej.

Zespół Cocoapods: Czy powinienem sprawdzić katalog Pods w celu kontroli źródła?

To zależy osobiście:

Dlaczego strąki powinny być częścią repozytorium (pod kontrolą źródła) i nie powinny być ignorowane

• Źródło jest identyczne
• Możesz go zbudować od razu (nawet bez kokosów)
• Nawet jeśli kapsuła zostanie usunięta, nadal mamy jej kopię (Tak, może się to zdarzyć i tak się stało. W starym projekcie, w którym chcesz tylko niewielkiej zmiany, musisz zaimplementować nową bibliotekę, aby móc nawet zbudować).
• pods.xcodeprojustawienia są również częścią kontroli źródła. Oznacza to, że np. Jeśli masz projekt swift 4, ale niektóre zasobniki muszą być dostępne, swift 3.2ponieważ nie zostały jeszcze zaktualizowane, ustawienia te zostaną zapisane. W przeciwnym razie ten, kto sklonował repo, popełniłby błędy.
• Zawsze możesz usunąć strąki z projektu i uruchomić pod install, nie można tego zrobić odwrotnie.
• Polecają to nawet autorzy Cocoapods.

Niektóre minusy: większe repozytorium, mylące różnice (głównie dla członków zespołu), potencjalnie więcej konfliktów.

Dla mnie największym zmartwieniem jest sprawdzenie w przyszłości źródła. Jeśli planujesz, aby Twój projekt trwał przez jakiś czas, a CocoaPods kiedykolwiek zniknie lub źródło jednego ze strąków spadnie, nie będziesz miał szczęścia, jeśli spróbujesz zbudować świeżo z archiwum.

Można to złagodzić za pomocą okresowych pełnych archiwów źródłowych.

Sprawdź w kapsułach.

Myślę, że powinien to być dogmat tworzenia oprogramowania

• Wszystkie kompilacje muszą być odtwarzalne
• Jedynym sposobem na zapewnienie powtarzalności kompilacji jest kontrolowanie wszystkich zależności; sprawdzanie wszystkich zależności jest zatem koniecznością.
• Nowy programista, zaczynając od zera, będzie mógł sprawdzić Twój projekt i rozpocząć pracę.

Dlaczego?

CocoaPods lub dowolne inne biblioteki zewnętrzne mogą ulec zmianie, co może zepsuć wszystko. Albo mogą się przenieść, zmienić ich nazwę lub całkowicie usunąć. Nie możesz polegać na Internecie, aby przechowywać rzeczy dla siebie. Twój laptop mógł umrzeć i wystąpił krytyczny błąd w produkcji, który należy naprawić. Główny programista może zostać potrącony przez autobus, a jego zastępca musi zacząć działać w pośpiechu. I chciałbym, żeby ten ostatni był teoretycznym przykładem, ale tak naprawdę wydarzyło się przy startupie, z którym byłem. ROZERWAĆ.

Teraz, realistycznie, nie można tak naprawdę sprawdzać WSZYSTKICH zależności. Nie można sprawdzić obrazu maszyny, której użyto do tworzenia kompilacji; nie można sprawdzić dokładnej wersji kompilatora. I tak dalej. Istnieją realistyczne ograniczenia. Ale melduj się wszystko, co możesz - nie robienie tego tylko utrudnia życie. I nie chcemy tego.

Ostatnie słowo: Strąki nie są artefaktami do budowania. Artefakty budowania są generowane z twoich kompilacji. Twoja kompilacja używa kapsuł, a nie ich generowania. Nie jestem nawet pewien, dlaczego należy to omówić.

Plusy braku sprawdzania kontroli Pods/wersji (w subiektywnej kolejności ważności):

1. Wiele łatwiej jest łączyć zatwierdzenia i sprawdzać różnice w kodzie. Scalanie jest powszechnym źródłem problemów w bazie kodu, a to pozwala skupić się tylko na rzeczach, które są istotne.
2. Niektórzy losowi współpracownicy nie są w stanie samodzielnie edytować zależności i sprawdzać zmian, których nigdy nie powinni robić (i ponownie trudno byłoby ustalić, czy różnica jest ogromna). Edytowanie zależności jest bardzo złą praktyką, ponieważ ma przyszłośćpod install zmiany mogą zostać zablokowane.
3. Rozbieżności między katalogiem Podfilea Pods/katalogiem są wykrywane szybciej wśród członków drużyny. Jeśli się zameldujesz Pods/i na przykład zaktualizujesz wersję w Podfile, ale zapomnisz uruchomić pod installlub wprowadzić zmiany w Pods/, będziesz miał o wiele trudniej zauważyć źródło rozbieżności. Jeśli Pods/nie jest zalogowany, zawsze musisz pod installmimo wszystko uruchomić .
4. Mniejszy rozmiar repozytorium. Mniejszy bajt-ślad jest fajny, ale to nie ma wielkiego znaczenia w wielkim schemacie. Co ważniejsze: posiadanie większej liczby rzeczy w repozytorium również zwiększa obciążenie poznawcze. Nie ma powodu, aby mieć w repozytorium rzeczy, na które nie powinieneś patrzeć. Zapoznaj się z dokumentacją (abstrakcja), aby dowiedzieć się, jak coś działa, a nie z kodem (implementacja).
5. Łatwiej rozróżnić, ile ktoś wnosi (ponieważ jego wiersze kodu nie zawierają zależności, których nie napisały)
6. JARpliki .venv/(środowiska wirtualne) i node_modules/nigdy nie są uwzględniane w kontroli wersji. Gdybyśmy byli całkowicie agnostykiem o pytaniu, nie sprawdzając w Podsbędzie domyślnym na podstawie precedensu.

Wady braku odprawy wPods/

1. Musisz uruchomić pod installpodczas przełączania gałęzi lub cofania zatwierdzeń.
2. Nie można uruchomić projektu po prostu poprzez klonowanie repozytorium. Musisz zainstalować narzędzie pod, a następnie uruchomić pod install.
3. Aby uruchomić pod install, musisz mieć połączenie z Internetem , a źródło strąków musi być dostępne.
4. Jeśli właściciel zależności usunie swój pakiet, masz kłopoty.

Podsumowując, nie wliczając w Podskatalogu jest poręczy przeciwko więcej złych praktyk. Włącznie z PodsTworzy katalog prowadzenie projektu łatwiejsze. Wolę ten pierwszy od drugiego. Nie będziesz musiał rozmawiać z każdą nową osobą na temat projektu „czego nie robić”, jeśli nie ma możliwości popełnienia pewnych błędów. Podoba mi się również pomysł posiadania osobnej kontroli wersji, Podsktóra łagodzi wady.

Teoretycznie powinieneś sprawdzić w katalogu Pods. W praktyce nie zawsze zadziała. Wiele zasobników znacznie przekracza limit rozmiaru plików github, więc jeśli używasz github, będziesz mieć problemy ze sprawdzaniem w katalogu Pods.

TL; DR: kiedy śledzisz Pods/folder, projekt jest łatwiejszy do pobrania. Kiedy go nie śledzisz, łatwiej jest ulepszyć, gdy pracujesz w zespole.

Chociaż organizacja Cocoapods zachęca nas do śledzenia Pods/ katalogu, mówią, że to deweloperzy decydują, czy zrobić to na podstawie tych zalet i wad:  http://guides.cocoapods.org/using/using-cocoapods.html # should-i-check-the-pods-directory-into-source-control

Osobiście zwykle śledzę Pods/ folder tylko w przypadku projektów, nad którymi nie będę dłużej pracował. W ten sposób każdy programista może szybko z niego skorzystać i kontynuować pracę przy użyciu odpowiedniej wersji cocoapods.

Z drugiej strony, myślę, że historia zatwierdzeń staje się czystsza i łatwiej jest scalić kod i przejrzeć kod innej osoby, gdy nie śledzisz Pods/ folderu. Zazwyczaj ustawiam wersję biblioteki cocoapod podczas instalacji, aby upewnić się, że każdy może zainstalować projekt przy użyciu tych samych wersji co ja.

Ponadto, gdy Pods/katalog jest śledzony, wszyscy deweloperzy muszą używać tej samej wersji Cocoapods, aby zapobiec zmianie dziesiątek plików przy każdym uruchomieniupod install aby dodać / usunąć kapsułę.

Konkluzja : podczas śledzenia Pods/folderu łatwiej jest pobrać projekt. Kiedy go nie śledzisz, łatwiej jest go ulepszyć.

Wydaje się, że dobrym sposobem na ustrukturyzowanie tego byłoby utworzenie katalogu „Pods” jako submodułu / osobnego projektu git, oto dlaczego.

• Posiadanie podsystemów w repozytorium projektu, podczas pracy z kilkoma programistami, może powodować BARDZO DUŻE różnice w żądaniach ściągania, w których prawie niemożliwe jest zobaczenie faktycznej pracy, która została zmieniona przez ludzi (pomyśl, że dla bibliotek zmieniło się kilkaset tysięcy plików, a tylko kilka zmieniło się w rzeczywistym projekcie).

• Widzę problem polegający na tym, aby nic nie popełniać, ponieważ osoba posiadająca bibliotekę może ją usunąć w dowolnym momencie, a ty jesteś w zasadzie SOL, rozwiązuje to również.

Niezależnie od tego, czy zaznaczysz folder Pods, zależy od Ciebie, ponieważ przepływy pracy różnią się w zależności od projektu. Zalecamy trzymanie katalogu Pods pod kontrolą źródła i nie dodawanie go do swojego .gitignore. Ale ostatecznie decyzja należy do Ciebie:

Korzyści ze sprawdzania w katalogu Pods

1. Po klonowaniu repozytorium projekt może natychmiast zbudować i uruchomić, nawet bez zainstalowania CocoaPods na maszynie. Nie ma potrzeby uruchamiania instalacji pod i nie jest wymagane połączenie z Internetem.
2. Artefakty kapsuły (kod / biblioteki) są zawsze dostępne, nawet jeśli źródło kapsuły (np. GitHub) miałoby spaść.
3. Po sklonowaniu repozytorium artefakty Kapsuły są identyczne z tymi w oryginalnej instalacji.

Korzyści z ignorowania katalogu Pods

1. Repozytorium kontroli źródła będzie mniejsze i zajmie mniej miejsca. Tak długo, jak dostępne są źródła (np. GitHub) dla wszystkich kapsuł, CocoaPods jest w stanie odtworzyć tę samą instalację. (Technicznie nie ma gwarancji, że uruchomiona instalacja kapsuły pobierze i odtworzy identyczne artefakty, gdy nie będzie używać SHA zatwierdzenia w pliku podfile Jest to szczególnie prawdziwe, gdy używasz plików zip w Podfile.)
2. Podczas wykonywania operacji kontroli źródła nie będzie żadnych konfliktów, takich jak łączenie oddziałów z różnymi wersjami Pod. Bez względu na to, czy sprawdzasz katalog Pods, Podfile i Podfile.lock powinny zawsze być pod kontrolą wersji.