私は数か月前からiOS開発を行っており、依存関係管理のための有望なCocoaPodsライブラリについて学んだところです。

私は個人的なプロジェクトでそれを試してみた：への依存関係を追加しましたキウイ私Podfile、走っにpod install CocoaPodsTest.xcodeproj、と出来上がり、それがとてもうまくいきました。

私が疑問に思っている唯一のことは、何をチェックインし、バージョン管理のために何を無視するかです。Podfile自体と、おそらく.xcworkspaceファイルもチェックインしたいのは明らかです。しかし、Pods /ディレクトリを無視しますか？.gitignoreにも追加する必要がある、他の依存関係を追加するときに、今後生成される他のファイルはありますか？

個人的に私はポッドディレクトリとコンテンツをチェックしません。影響を考慮して長い時間を費やしたとは言えませんが、私の推論は次のようなものです。

ポッドファイルは特定のタグまたは各依存関係のコミットを参照するため、ポッド自体をポッドファイルから生成できます。つまり、ポッドファイルはソースよりも中間ビルド製品のようであり、したがって、プロジェクトでバージョン管理を行う必要はありません。

ポッドディレクトリをコミットします。ポッドディレクトリがビルドアーティファクトであることに同意しません。実際、私は間違いなくそうではないと言います。これはアプリケーションソースの一部です。それなしではビルドできません！

CocoaPodsは、ビルドツールではなく開発者ツールと考える方が簡単です。プロジェクトをビルドするのではなく、依存関係を複製してインストールするだけです。プロジェクトを簡単にビルドできるようにするために、CocoaPodsをインストールする必要はありません。

CocoaPodsをビルドの依存関係にすることで、プロジェクトのビルドに必要なすべての場所で利用できるようにする必要があります...チーム管理者が必要とし、CIサーバーがそれを必要とします。原則として、ソースリポジトリのクローンを作成し、それ以上の作業をせずにビルドできるようにする必要があります。

ポッドディレクトリをコミットしないと、ブランチを頻繁に切り替える場合にも大きな頭痛の種になります。次に、ブランチを切り替えるたびにpod installを実行して、依存関係が正しいことを確認する必要があります。依存関係が安定するので、これはそれほど面倒ではないかもしれませんが、プロジェクトの早い段階でこれは大きな時間のシンクになります。

それで、私は何を無視しますか？何もない。Podfile、ロックファイル、およびPodsディレクトリがすべてコミットされます。私を信じて、それはあなたに多くの面倒を救います。短所は何ですか？少し大きいレポ？世界の終わりではありません。

GitHubのObjective-C gitignoreを使用することをお勧めします。詳細には、ベストプラクティスは次のとおりです。

• Podfile 必要があり、常にソース管理下にあります。
• Podfile.lock 必要があり、常にソース管理下にあります。
• CocoaPodsによって生成されたワークスペースは、ソース管理下に置く必要があります。
• :pathオプションで参照されるポッドはすべてソース管理下に置く必要があります。
• ./Podsフォルダができ、ソース管理下に保つこと。

詳細については、公式ガイドを参照してください。

出典：@alloyなど、CocoaPodsコアチームのメンバーです

Podsフォルダーはビルドアーティファクトですが、ソース管理下に置くかどうかを決定する際に考慮すべき理由がいくつかあります。

• CocoaPodsはパッケージマネージャーではないため、ライブラリの元のソースは作成者によって将来削除される可能性があります。
• Podsフォルダがソース管理に含まれている場合、チェックアウトで十分なので、プロジェクトを実行するためにCocoaPodsをインストールする必要はありません。
• CocoaPodsはまだ作業中です。常に同じ結果をもたらすとは限らないオプションがあります（たとえば、:headおよび:gitオプションは現在、に格納されているコミットを使用していませんPodfile.lock）。
• 中/長時間後にプロジェクトの作業を再開する場合は、障害点が少なくなります。

.gitignoreファイル

答えは実際にはを提供し.gitignoreないので、ここに2つのフレーバーがあります。

ポッドディレクトリのチェックイン（利点）

Xcode / iOSフレンドリーなgit無視、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/

ポッドディレクトリを無視する（利点）

.gitignore：（ 前のリストに追加）

# Cocoapods
Pods/

Podsディレクトリをチェックインするかどうかにかかわらず、PodfileとPodfile.lockは常にバージョン管理下に置く必要があります。

Podsチェックインされていない場合は、PodfileCocoapodごとにバージョン番号を明示的に要求する必要があります。Cocoapods.orgのディスカッションはこちら。

私は通常、クライアントのアプリで作業します。その場合、ポッドディレクトリをリポにも追加して、任意の時点で開発者がチェックアウトを実行し、ビルドして実行できるようにします。

それが私たち自身のアプリである場合は、しばらく作業しないまで、おそらくPodsディレクトリを除外します。

実際、私は純粋なユーザーの見解に対して、私があなたの質問に答えるのに最高の人ではないかもしれないと結論づけなければなりません:)私はこの質問についてhttps://twitter.com/CocoaPodsOrgからツイートします。

私はすべてをチェックインします。（Pods/およびPodfile.lock。）

リポジトリのクローンを作成し、アプリを前回使用したときと同じようにすべてが機能することを知りたいです。

ジェムの異なるバージョンや誰かがポッドのリポジトリの履歴を書き直したことなどが原因で異なる結果が生じるリスクを負うよりも、むしろ物事を売り込むほうがいいです。

この答えは、Cocoapodのドキュメントに直接記載されています。「http://guides.cocoapods.org/using/using-cocoapods.html#should-i-ignore-the-pods-directory-in-source-control」をご覧ください。

ワークフローはプロジェクトごとに異なるため、Podsフォルダーをチェックインするかどうかはあなた次第です。ポッドディレクトリはソース管理下に置き、.gitignoreに追加しないことをお勧めします。しかし最終的には、この決定はあなた次第です。

ポッドディレクトリをチェックインする利点

• リポジトリにクローンを作成した後、CocoaPodsがマシンにインストールされていなくても、プロジェクトをすぐにビルドして実行できます。ポッドインストールを実行する必要はなく、インターネット接続も必要ありません。
• ポッドのソース（GitHubなど）がダウンした場合でも、ポッドアーティファクト（コード/ライブラリ）はいつでも利用できます。
• ポッドアーティファクトは、レポのクローンを作成した後、元のインストールのアーティファクトと同一であることが保証されています。

ポッドディレクトリを無視する利点

• ソース管理リポジトリは小さくなり、占有するスペースも少なくなります。

• すべてのポッドのソース（GitHubなど）が利用可能である限り、CocoaPodsは通常、同じインストールを再作成できます。（技術的には、Podfileでcommit SHAを使用していない場合、実行中のpod installが同一のアーティファクトをフェッチして再作成する保証はありません。これは、Podfileでzipファイルを使用する場合に特に当てはまります。）

• ブランチを異なるポッドバージョンにマージするなど、ソース管理操作を実行するときに対処する必要のある競合はありません。

Podsディレクトリをチェックインするかどうかにかかわらず、PodfileとPodfile.lockは常にバージョン管理下に置く必要があります。

私は、ライブラリをチェックインしない開発者の陣営にいます。別の場所に適切なコピーがあると想定しています。したがって、私の.gitignoreには、CocoaPodsに固有の次の行を含めます。

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

次に、ライブラリのコピーが安全な場所にあることを確認します。プロジェクトのコードリポジトリを（誤って）使用して依存関係（コンパイルされているかどうかにかかわらず）を格納するのではなく、ビルドをアーカイブするのが最善の方法だと思います。ビルド（Jenkinsなど）にCIサーバーを使用する場合、重要なビルドを永久にアーカイブできます。すべてのプロダクションビルドをローカルXcodeで行う場合は、保持する必要のあるすべてのビルドについて、プロジェクトのアーカイブを作成するようにしてください。次のようなもの：1.製品->アーカイブ

1. 配布... iOS App Storeに送信する/エンタープライズまたはアドホック展開用に保存する/何を持っているか

2. Finderでプロジェクトフォルダを表示する

3. 右クリックして「WhateverProject」を圧縮

CocoaPodsを使用するかどうかに関係なく、アプリのビルドに使用される完全なプロジェクトとワークスペースの設定、およびバイナリ配布（Sparkle、TestFlightなどの独自のSDKなど）を含む、プロジェクト全体のビルド済みイメージを提供します。

更新：私はこれについて考えを変え、今はPodfile.lockソース管理にコミットします。ただし、ポッド自体はビルドアーティファクトであり、CIサーバーや上記で説明したようなアーカイブプロセスなどの別の方法で、ソース管理外で管理する必要があると私はまだ信じています。

私はコミット好むPodsと一緒にディレクトリをPodfileし、Podfile.lock私のチームで確認してください誰もがソースをいつでもチェックアウトすることができ、彼らは何も心配する必要はありまたはそれを動作させるために追加的なものをしないようにします。

これは、ポッドの1つでバグを修正したり、必要に応じて一部の動作を変更したりするシナリオにも役立ちますが、コミットしないと、これらの変更は他のマシンでは利用できません。

不要なディレクトリを無視するには：

xcuserdata/

私は言わなければなりません、私はポッドをリポジトリにコミットするのが好きです。すでに述べたリンクをたどると、ポッドを許可するiOS用のXcodeプロジェクトを立ち上げるための優れた.gitignoreファイルが提供されますが、必要に応じて簡単に除外することもできます。https：//github.com/github/gitignore/ blob / master / Objective-C.gitignore

ポッドをリポジトリに追加することのファンである私の推論は、誰も取り上げていないように見える基本的な理由の1つです。プロジェクトが依存しているライブラリが突然Webから削除された場合はどうなりますか？

• おそらく、ホストがGitHubアカウントを開いたままにしないことを決定した可能性があります。ライブラリが数年前（たとえば5年以上）であるとすると、プロジェクトがソースで利用できなくなる可能性が高いというリスクがあります。
• また、リポジトリへのURLが変更された場合はどうなりますか？GitHubアカウントからポッドにサービスを提供している人が、別のハンドルで自分自身を表すことにしたとしましょう-ポッドURLは壊れます。
• 最後に別のポイント。私のように、国を行き来する際に多くのコーディングを行う開発者であるとします。私は「マスター」ブランチをすばやくプルし、そのブランチにポッドインストールを行います。空港に座っている間、次の8時間のフライトの準備がすべて整いました。フライトに3時間入ったところ、別のブランチに切り替える必要があることに気付きました。「DOH」-「マスター」ブランチでのみ利用可能なポッド情報がありません。

注：開発用の「マスター」ブランチは単なる例であり、バージョン管理システムの「マスター」ブランチは、いつでもクリーンに保ち、デプロイ/ビルド可能にしておく必要があります。

これらから、コードリポジトリのスナップショットは、リポジトリのサイズを厳密にするよりも確かに優れていると思います。そしてすでに述べたように、podfile.lockファイル-バージョン管理されている間、ポッドバージョンの良い履歴が得られます。

1日の終わりに、差し迫った期限があり、予算が厳しい場合は、時間が重要です。厳密なイデオロギーに時間を無駄にせず、できるだけリソースを活用する必要があります。代わりに、一連のツールを利用して連携します。 -私たちの生活をより効率的にするため。

最後にあなたが取るアプローチはあなた次第です。

Cocoapodsチームはこれについて次のように考えています。

ワークフローはプロジェクトごとに異なるため、Podsフォルダーをチェックインするかどうかはあなた次第です。ポッドディレクトリはソース管理下に置き、.gitignoreに追加しないことをお勧めします。しかし、最終的にこの決定はあなた次第です。

個人的に私は維持したいポッドとして、アウトnode_modules私が使用していた場合はノードまたはbower_componentsを私は使用していた場合バウアーを。これは、ほとんどすべての依存関係マネージャーに当てはまり、gitサブモジュールの背後にある哲学でもあります。

ただし、特定の依存関係の最先端について本当に確認したい場合があるかもしれません。そうすれば、プロジェクト内で依存関係を自分で持ち運ぶことができます。もちろん、それを行う場合に適用されるいくつかの欠点がありますが、懸念はCocoaPodsにのみ適用されるのではなく、そこにあるすべての依存関係マネージャーに適用されます。

以下は、Cocoapodsチームが作成した良い賛否両論のリストと、前述の引用の全文です。

Cocoapodsチーム：ポッドディレクトリをソース管理にチェックインする必要がありますか？

それは個人的に異なります：

ポッドが（ソース管理下の）リポジトリの一部であり、無視されるべきではない理由

• ソースは同じです
• そのまま（cocoapodsがなくても）すぐに構築できます。
• ポッドが削除されても、そのコピーは残ります（はい、これは発生する可能性があり、実際に発生しました。小さな変更だけが必要な古いプロジェクトでは、ビルドできるように新しいライブラリを実装する必要があります）。
• pods.xcodeproj設定もソース管理の一部です。つまり、たとえばにプロジェクトがあるがswift 4、swift 3.2まだ更新されていないために一部のポッドが存在している必要がある場合、これらの設定は保存されます。そうしないと、レポを複製した人がエラーになってしまいます。
• いつでもプロジェクトからポッドを削除して実行pod installできますが、その逆はできません。
• Cocoapods の作者でさえも推奨しています。

いくつかの短所：リポジトリが大きい、差分（主にチームメンバーの場合）が混乱している、潜在的に競合が多い。

私にとって、最大の懸念は、ソースの将来的な証明です。しばらくプロジェクトを継続する予定で、CocoaPodsがなくなるか、いずれかのポッドのソースがダウンした場合、アーカイブから最新のビルドを作成しようとしても、まったくうまくいきません。

これは、定期的な完全なソースアーカイブで軽減できます。

ポッドをチェックインします。

これはソフトウェア開発の信条であるべきだと思います

• すべてのビルドは再現可能でなければなりません
• ビルドを再現可能にする唯一の方法は、すべての依存関係を制御することです。したがって、すべての依存関係をチェックインする必要があります。
• ゼロから始める新しい開発者は、プロジェクトをチェックアウトして作業を開始できます。

どうして？

CocoaPodsまたはその他の外部ライブラリが変更され、問題が発生する可能性があります。または、移動したり、名前を変更したり、完全に削除したりすることもできます。物を保管するためにインターネットに依存することはできません。あなたのラップトップは死んだかもしれません、そして修正される必要がある生産に重大なバグがあります。メインの開発者はバスに襲われる可能性があり、彼の代わりの開発者は急いで立ち上がる必要があります。最後の1つが理論的な例であることを願っていますが、実際には私が一緒にいたスタートアップで起こりました。RIP。

現在、現実的には、すべての依存関係を実際にチェックインすることはできません。ビルドの作成に使用したマシンのイメージをチェックインすることはできません。コンパイラの正確なバージョンをチェックインすることはできません。等々。現実的な限界があります。しかし、できることはすべてチェックインしてください。そうしないと、人生がより困難になります。そして、私たちはそれを望んでいません。

最後の言葉：ポッドはビルドアーティファクトではありません。ビルドアーティファクトは、ビルドから生成されるものです。ビルドはポッドを使用し、生成はしません。なぜこれが議論されなければならないのか私にはわかりません。

バージョン管理にチェックインしないことの主な利点Pods/（重要度の高い順に）：

1. コミットをマージし、コードの差分を確認する方がはるかに簡単です。マージはコードベースの問題の一般的な原因であり、これにより、適切なものにのみ焦点を合わせることができます。
2. 一部のランダムな寄稿者が依存関係を自分で編集して変更をチェックすることは不可能ですが、それらを行うべきではありません（この場合も、diffが大量であるかどうかを特定するのは困難です）。依存関係の編集は非常に悪い習慣です。pod installに変更が隠される可能性があるです。
3. PodfileとPods/ディレクトリの不一致は、チームメイトの方が早く見つかります。チェックインしPods/て、たとえばでバージョンを更新し、Podfile実行を忘れpod installたり、への変更をチェックインしたりするPods/と、不一致の原因に気づくのがはるかに困難になります。Pods/がチェックインされていない場合は、pod installとにかく常に実行する必要があります。
4. より小さいレポサイズ。バイトフットプリントを小さくするのは良いことですが、グランドスキームではそれほど重要ではありません。さらに重要なことは、リポジトリ内により多くのものを置くことはまた、認知負荷を増加させます。リポジトリに、見るべきではないものがある理由はありません。コード（実装）ではなく、何かがどのように機能するかを知るには、ドキュメント（抽象化）を参照してください。
5. 誰かがどれだけ貢献しているかを識別するのがより簡単になりました（貢献した彼らのコード行には、自分が記述し​​ていない依存関係が含まれないため）
6. JARファイル.venv/（仮想環境）、およびnode_modules/バージョン管理に含まれることはありません。我々は、質問について完全にとらわれないであれば、いないチェックインPods先例に基づいてデフォルトになります。

チェックインしないことの短所Pods/

1. pod installブランチを切り替えるとき、またはコミットを元に戻すときに実行する必要があります。
2. リポジトリを複製するだけではプロジェクトを実行できません。ポッドツールをインストールしてから、を実行する必要がありますpod install。
3. を実行するにはインターネット接続がpod install必要で、ポッドのソースが利用可能である必要があります。
4. 依存関係の所有者がパッケージを削除すると、問題が発生します。

要約すると、ディレクトリを含めないことPodsは、より多くの悪い慣行に対するガードレールです。Podsディレクトリを含めると、プロジェクトの実行が容易になります。私は後者よりも前者を好む。そもそも特定の間違いをする可能性がない場合は、プロジェクトのすべての新しい人に「何をすべきでないか」について報告する必要はありません。またPods、短所を軽減するためのバージョン管理を別にするというアイデアも気に入っています。

理論的には、Podsディレクトリをチェックインする必要があります。実際には、常に機能するとは限りません。多くのポッドはgithubファイルのサイズ制限を十分に超えているため、githubを使用している場合は、ポッドディレクトリでのチェックで問題が発生します。

TL; DR：Pods/フォルダーを追跡すると、プロジェクトを簡単にピックアップできます。追跡しない場合は、チームで作業するときに改善する方が簡単です。

Cocoapods組織はPods/ディレクトリを追跡することを推奨していますが、これらの長所と短所に基づいてそれを行うかどうかを決定するのは開発者の責任だと言っています。  http //guides.cocoapods.org/using/using-cocoapods.html ＃should-i-check-the-pods-directory-into-source-control

個人的には、私は通常Pods/、しばらく作業しないプロジェクトのためにフォルダーを追跡します。そうすれば、開発者はすぐにそれを拾い上げ、適切なバージョンのココアポッドを使用して作業を続けることができます。

一方、私はコミット履歴がきれいになり、コードをマージしたり、追跡していないときに他の人のコードをレビューしたりするのが簡単になると思います Pods/フォルダーをます。私は通常、インストール時にcocoapodライブラリのバージョンを設定して、誰でも私と同じバージョンを使用してプロジェクトをインストールできるようにします。

また、Pods/ディレクトリが追跡されている場合、すべての開発者は同じバージョンのCocoapodを使用して、実行するたびに数十のファイルが変更されないようにする必要があります。pod install、ポッドを追加/削除するためにする。

結論：Pods/フォルダーを追跡すると、プロジェクトを簡単にピックアップできます。追跡しない場合は、改善する方が簡単です。

これを構造化するための良い方法のように思えるのは、「Pods」ディレクトリをgitサブモジュール/別のプロジェクトとして持つことです。これが理由です。

• プロジェクトリポジトリにポッドがあると、複数の開発者と共同で作業しているときに、プルリクエストで非常に大きな差異が発生する可能性があります。実際のプロジェクトではほとんど変更されていません）。

• ライブラリを所有している人はいつでもライブラリを削除でき、あなたは本質的にSOLなので、gitに何もコミットしないという問題が発生します。これも解決します。

ワークフローはプロジェクトごとに異なるため、Podsフォルダーをチェックインするかどうかはあなた次第です。ポッドディレクトリはソース管理下に置き、.gitignoreに追加しないことをお勧めします。しかし最終的には、この決定はあなた次第です。

ポッドディレクトリをチェックインする利点

1. リポジトリにクローンを作成した後、CocoaPodsがマシンにインストールされていなくても、プロジェクトをすぐにビルドして実行できます。ポッドインストールを実行する必要はなく、インターネット接続も必要ありません。
2. ポッドのソース（GitHubなど）がダウンした場合でも、ポッドアーティファクト（コード/ライブラリ）はいつでも利用できます。
3. ポッドアーティファクトは、レポのクローンを作成した後、元のインストールのアーティファクトと同一であることが保証されています。

ポッドディレクトリを無視する利点

1. ソース管理リポジトリは小さくなり、占有するスペースも少なくなります。すべてのポッドのソース（GitHubなど）が利用可能である限り、CocoaPodsは通常、同じインストールを再作成できます（技術的には、ポッドインストールでコミットSHAを使用していない場合、ポッドインストールを実行すると同一のアーティファクトがフェッチおよび再作成される保証はありません。 。これは、Podfileでzipファイルを使用する場合に特に当てはまります。）
2. ブランチを異なるポッドバージョンにマージするなど、ソース管理操作を実行するときに対処する必要のある競合はありません。Podsディレクトリをチェックインするかどうかにかかわらず、PodfileとPodfile.lockは常にバージョン管理下に置く必要があります。