私は数か月間 iOS 開発を行っており、依存関係管理に有望なCocoaPodsライブラリについて知りました。
私は個人的なプロジェクトで試してみました.Kiwiへの依存関係をPodfileに追加し、 run 、voila 、うまくいきましpod install CocoaPodsTest.xcodeprojた。
私が疑問に思っている唯一のことは、何をチェックインし、バージョン管理のために何を無視するのかということです。Podfile 自体と、おそらく .xcworkspace ファイルもチェックインしたいのは明らかです。しかし、Pods/ ディレクトリは無視しますか? 今後 (他の依存関係を追加するときに) 生成される他のファイルもあり、.gitignore にも追加する必要がありますか?
Pods ディレクトリをコミットします。Pods ディレクトリがビルド アーティファクトであることに同意しません。実際、それは間違いなくそうではないと思います。これはアプリケーション ソースの一部です。これなしではビルドできません。
CocoaPods は、ビルド ツールではなく開発者ツールと考える方が簡単です。プロジェクトをビルドするのではなく、依存関係を複製してインストールするだけです。プロジェクトを簡単にビルドできるようにするために CocoaPods をインストールする必要はありません。
CocoaPods をビルドの依存関係にすることで、プロジェクトのビルドに必要なあらゆる場所で CocoaPods を利用できるようにする必要があります...チーム管理者が必要とし、CI サーバーがそれを必要とします。原則として、ソース リポジトリのクローンを常に作成し、それ以上の作業を行わなくてもビルドできるようにする必要があります。
ブランチを頻繁に切り替える場合、Pods ディレクトリをコミットしないことも大きな頭痛の種になります。ブランチを切り替えるたびに pod install を実行して、依存関係が正しいことを確認する必要があります。依存関係が安定するにつれて、これはそれほど手間がかからないかもしれませんが、プロジェクトの初期段階では、これは膨大な時間の浪費になります。
それで、私は何を無視しますか？何もない。Podfile、ロック ファイル、および Pods ディレクトリはすべてコミットされます。私を信じてください、それはあなたに多くの手間を省きます. 短所は何ですか？少し大きいレポ？世界の終わりではありません。
個人的には、Pods ディレクトリとコンテンツをチェックインしません。その影響を考えるのに長い年月を費やしたとは言えませんが、私の推論は次のようなものです。
Podfile は、各依存関係の特定のタグまたはコミットを参照するため、Pod 自体は Podfile から生成できます。したがって、Podfile はソースというよりも中間ビルド製品に似ているため、プロジェクトでバージョン管理は必要ありません。
実際にを提供する答えは.gitignoreないので、ここに 2 つのフレーバーがあります。
Pods ディレクトリにチェックインする(利点)
Xcode/iOS フレンドリーな git ignore、Mac OS システム ファイル、Xcode、ビルド、その他のリポジトリとバックアップをスキップします。
.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/
Pods ディレクトリを無視する(利点)
.gitignore: (前のリストに追加)
# Cocoapods
Pods/
Pods ディレクトリをチェックインするかどうかに関係なく、Podfile と Podfile.lock は常にバージョン管理下に置かれる必要があります。
Podsチェックインされていない場合は、 PodfileCocoapod ごとに明示的なバージョン番号を要求する必要があります。Cocoapods.org のディスカッションはこちら。
私は通常、アプリのクライアントに取り組んでいます。その場合、Pods ディレクトリもレポに追加して、いつでも開発者がチェックアウトしてビルドして実行できるようにします。
それが私たち自身のアプリである場合、しばらく作業を停止するまで Pods ディレクトリを除外するでしょう。
実際、純粋なユーザーの意見と比較して、私はあなたの質問に答えるのに最適な人物ではないかもしれないと結論付けなければなりません:) この質問についてはhttps://twitter.com/CocoaPodsOrgからツイートします。
私はすべてをチェックインします。(Pods/とPodfile.lock。)
リポジトリのクローンを作成して、前回アプリを使用したときと同じようにすべてが機能することを確認したいと考えています。
Gem のバージョンが異なることや、誰かが Pod のリポジトリの履歴を書き換えることなどによって異なる結果が生じる危険を冒すよりも、むしろ物を売り込みたいと思います。
私は、ライブラリをチェックインしない開発者の陣営にいます。別の場所に適切なコピーがあると仮定してのことです。そこで、私の .gitignore には、CocoaPods に固有の次の行を含めます。
Pods/
#Podfile.lock # changed my mind on Podfile.lock
次に、ライブラリのコピーが安全な場所にあることを確認します。プロジェクトのコード リポジトリを (コンパイル済みかどうかに関係なく) 依存関係を保存するために (誤って) 使用するのではなく、ビルドをアーカイブするのが最善の方法だと思います。ビルドに CI サーバー (Jenkins など) を使用する場合、重要なビルドを永続的にアーカイブできます。すべての本番ビルドをローカルの Xcode で行う場合は、保持する必要があるビルドのためにプロジェクトのアーカイブを作成する習慣をつけてください。1. 製品 --> アーカイブ
配布... iOS App Store に提出 / エンタープライズまたはアドホック展開用に保存 / 持っているもの
Finder でプロジェクト フォルダーを表示する
右クリックして「WhateverProject」を圧縮します
これにより、CocoaPods を使用するかどうかに関係なく、アプリのビルドに使用される完全なプロジェクトとワークスペースの設定、およびバイナリ ディストリビューション (Sparkle、TestFlight などの独自の SDK など) を含む、プロジェクト全体のビルド済みイメージが提供されます。
更新:これについて気が変わったので、Podfile.lockソース管理にコミットします。ただし、ポッド自体はビルド アーティファクトであり、CI サーバーや上記のようなアーカイブ プロセスなどの別の方法を通じて、ソース管理の外部でそのように管理する必要があると考えています。
私のチームの誰もがいつでもソースをチェックアウトできるようにするために、Podsディレクトリをコミットすることを好みます。PodfilePodfile.lock
これは、いずれかのポッド内のバグを修正したり、必要に応じていくつかの動作を変更したりしたものの、コミットされていない場合、これらの変更が他のマシンで利用できないというシナリオにも役立ちます。
不要なディレクトリを無視するには:
xcuserdata/
私はポッドをリポジトリにコミットするのが好きだと言わざるを得ません。前述のリンクをたどると、iOS 用の Xcode プロジェクトを起動して Pod を許可するための適切な .gitignore ファイルが得られますが、必要に応じてそれらを簡単に除外することもできます: https://github.com/github/gitignore/ブロブ/マスター/Objective-C.gitignore
私が Pod をリポジトリに追加することのファンである理由は、誰も理解していないように見える 1 つの根本的な理由によるものです。私たちのプロジェクトが非常に依存しているライブラリが突然 Web から削除されたらどうなるでしょうか?
NB...開発用の「マスター」ブランチは単なる例であることに注意してください。バージョン管理システムの明らかに「マスター」ブランチは、いつでもクリーンでデプロイ可能/ビルド可能に保つ必要があります
これらのことから、コード リポジトリのスナップショットは、リポジトリ サイズに厳密であるよりも確実に優れていると思います。すでに述べたように、podfile.lock ファイル - バージョン管理されている間、Pod バージョンの良好な履歴が得られます。
締め切りが迫っていて、予算が限られている場合、結局のところ、時間が重要です。厳密なイデオロギーに時間を浪費するのではなく、可能な限り機知に富む必要があり、代わりに一連のツールを活用して連携する必要があります。 - 私たちの生活をより効率的にするために。
最終的にどのようなアプローチを取るかはあなた次第です。
Cocoapods チームは次のように考えています。
ワークフローはプロジェクトごとに異なるため、Pods フォルダーをチェックインするかどうかはあなた次第です。Pods ディレクトリをソース管理下に置き、.gitignore に追加しないことをお勧めします。しかし、最終的にこの決定はあなた次第です。
個人的には、 Nodeを使用している場合はnode_modules 、 Bowerを使用している場合はbower_componentsとして、ポッドを除外したいと思います。これは、ほとんどすべての Dependency Manager に当てはまり、git サブモジュールの背後にある哲学でもあります。
ただし、特定の依存関係の最新技術について本当に確認したい場合があります。そのようにして、プロジェクト内で依存関係を所有することができます。もちろん、それを行う場合に適用されるいくつかの欠点がありますが、懸念は Cocoapods だけに適用されるのではなく、そこにあるすべての Dependency Manager に適用されます。
以下は、Cocoapods チームによって作成された優れた長所と短所のリストと、前述の引用の全文です。
私にとって最大の関心事は、あなたの情報源を将来証明することです。プロジェクトをしばらく存続させる予定で、CocoaPods がなくなったり、ポッドの 1 つのソースがダウンしたりした場合、アーカイブから新たにビルドしようとしても、まったく運が悪いでしょう。
これは、定期的にソース全体をアーカイブすることで軽減できます。
理論的には、Pods ディレクトリをチェックインする必要があります。実際には、常にうまくいくとは限りません。多くの Pod は github ファイルのサイズ制限をはるかに超えているため、github を使用している場合、Pods ディレクトリのチェックで問題が発生します。
ワークフローはプロジェクトごとに異なるため、Pods フォルダーをチェックインするかどうかはあなた次第です。Pods ディレクトリをソース管理下に置き、.gitignore に追加しないことをお勧めします。しかし、最終的にこの決定はあなた次第です:
Pods ディレクトリにチェックインする利点
Pods ディレクトリを無視する利点
これを構造化する良い方法のように思われるのは、「Pods」ディレクトリを git サブモジュール / 別のプロジェクトとして持つことです。その理由は次のとおりです。
プロジェクト リポジトリにポッドがあると、複数の開発者と作業しているときに、プル リクエストで非常に大きな差分が発生する可能性があり、人々によって変更された実際の作業を確認することはほとんど不可能です (ライブラリ用に変更された数百から数千のファイルを考えてみてください。実際のプロジェクトではほとんど変更されていません)。
ライブラリを所有している人はいつでもライブラリを削除でき、あなたは本質的にSOLであるため、gitに何もコミットしないという問題が見られます。これも解決します。