CocoaPodを使用している場合、あなたの.gitignoreには何が入りますか？
私はここ数ヶ月間iOS開発をしていて、依存性管理のための有望な CocoaPods ライブラリについて学んだばかりです。
私は個人的なプロジェクトで試してみました。Podfileに Kiwi への依存関係を追加し、pod install CocoaPodsTest.xcodeprojを実行し、そしてvoila、うまくいった。
私が疑問に思うのは残された唯一のことです：私は何をチェックインすればいいですか、そしてバージョン管理のために何を無視しますか？ Podfile自体、そしておそらく.xcworkspaceファイルもチェックインしたいのは明らかです。しかし、Pods /ディレクトリを無視しますか？ .gitignoreに追加しなければならない、他の依存関係を追加するときに生成される他のファイルはありますか？
個人的に私はPodsディレクトリと内容をチェックインしません。その影響を考慮して長年過ごしたとは言えませんが、私の推論は次のようなものです。
PodfileはPodfileから生成できるように、各依存関係の特定のタグまたはコミットを参照するため、ソースというよりは中間ビルド製品に近いので、私のプロジェクトではバージョン管理は必要ありません。
Podsディレクトリをコミットします。 Podsディレクトリがビルドアーティファクトであることに同意しません。実際、私はそれが間違いなくそうであると言うでしょう。それはあなたのアプリケーションソースの一部です：それなしではビルドされません！
CocoaPodをビルドツールではなく開発者ツールと考えるほうが簡単です。プロジェクトを構築するのではなく、依存関係を複製してインストールします。プロジェクトを単純にビルドできるようにするためにCocoaPodをインストールする必要はありません。
CocoaPodをビルドの依存関係にすることで、プロジェクトをビルドする必要がある可能性があるすべての場所でCocoaPodを使用できるようにする必要があります。チーム管理者が必要とし、CIサーバーが必要です。原則として、ソースリポジトリのクローンを作成し、それ以上の努力をしなくても構築できるようにする必要があります。
頻繁にブランチを切り替える場合は、Podsディレクトリをコミットしないと大きな頭痛の種も発生します。依存関係が正しいことを確認するために、ブランチを切り替えるたびにpod installを実行する必要があります。あなたの依存関係が安定するので、これは面倒ではないかもしれません、しかしプロジェクトの早い段階でこれは大規模なタイムシンクです。
それで、私は何を無視しますか？何もない。 Podfile、ロックファイル、およびPodsディレクトリはすべてコミットされます。私を信頼してください、それはあなたに面倒の多くを救います。短所は何ですか？もう少し大きいレポ？世界の終わりではありません。
GitHubのObjective-C gitignore を使うことをお勧めします。詳細には、ベストプラクティスは次のとおりです。
Podfileは常にソース管理下に置く必要があります。Podfile.lockは常にソース管理下に置く必要があります。- CocoaPodsによって生成されたワークスペースはソース管理下に置かれるべきです。
:pathオプションで参照されているPodはすべてソース管理下に置く必要があります。./Podsフォルダはソース管理下に置くことができます。
詳しくは 公式ガイド を参照してください。
source：私は@alloyのように、CocoaPodsコアチームのメンバーです。
Podsフォルダはビルドアーティファクトですが、ソース管理下に置くことをより慎重に決定する際に考慮する必要がある理由があります。
- CocoaPodsはパッケージマネージャではないので、ライブラリの元のソースは将来作者によって削除される可能性があります。
- Podsフォルダがソース管理に含まれている場合、チェックアウトで十分なので、プロジェクトを実行するためにCocoaPodsをインストールする必要はありません。
- CocoaPodsはまだ進行中で、常に同じ結果にならないオプションがあります（例えば、
:headおよび:gitオプションは現在Podfile.lockに保存されているコミットを使用していません）。 - あなたが中長期の時間の後にプロジェクトの仕事を再開するかもしれないなら失敗の点が少ないです。
私は通常、アプリのクライアントに取り組んでいます。その場合は、Podsディレクトリをリポジトリに追加して、任意の開発者がいつでもチェックアウトを実行して構築および実行できるようにします。
それが私たち自身のアプリであれば、しばらく作業しない限りPodsディレクトリを除外します。
実際、純粋なユーザーの意見と比較して、私はあなたの質問に答えるのに最適な人物ではないかもしれないと結論づけなければなりません:)私は https://Twitter.com/CocoaPodsOrg からこの質問についてツイートします。
.gitignoreファイル
無回答は実際には.gitignoreを提供するので、ここに2つの種類があります。
Podsディレクトリをチェックインする（ 利点 ）
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/
Podsディレクトリを無視する（ 利点 ）
。gitignore：（前のリストに追加）
# Cocoapods
Pods/
Podsディレクトリをチェックインするかどうかにかかわらず、PodfileとPodfile.lockは常にバージョン管理下に置かれるべきです。
Podsがチェックインされていない場合、あなたのPodfileはおそらく各Cocoapodに対して明示的なバージョン番号を要求するべきです。 Cocoapods.orgの議論 ここ 。
私はすべてチェックインします。 （Pods/とPodfile.lock）
私はリポジトリのクローンを作成することができるようにしたいと思っていて、すべてが私が最後にアプリを使ったときと同じようにうまくいくことを知っています。
異なるバージョンのgem、または誰かがPodのリポジトリ内の履歴を書き換えたことなどによって、結果が異なる可能性があるというリスクよりも、むしろ物事をベンダーにしたいのです。
これに対する答えはCocoapodのドキュメントに直接あります。あなたは " http://guides.cocoapods.org/using/using-cocoapods.html#should-i-ignore-the-pods-directory-in-source-control "を見るかもしれません
ワークフローはプロジェクトによって異なるため、Podsフォルダをチェックインするかどうかはあなた次第です。 Podsディレクトリはソース管理下に置き、.gitignoreに追加しないことをお勧めします。しかし、最終的にはこの決定はあなた次第です。
Podsディレクトリをチェックインする利点
- リポジトリのクローンを作成した後、CocoaPodをマシンにインストールしなくても、プロジェクトをすぐにビルドして実行できます。 pod installを実行する必要はなく、インターネット接続も必要ありません。
- Podのソース（例：GitHub）が停止したとしても、Podアーティファクト（コード/ライブラリ）は常に利用可能です。
- Podアーティファクトは、レポのクローンを作成した後の元のインストールのものと同一であることが保証されています。
Podsディレクトリを無視することの利点
ソース管理レポジトリが小さくなり、占有スペースが少なくなります。
すべてのPodのソース（GitHubなど）が利用可能である限り、CocoaPodは一般的に同じインストールを再現することができます。 （技術的には、Podfileでcommit SHAを使用していない場合にpod installを実行しても同じ成果物がフェッチされて再作成されるという保証はありません。
異なるPodバージョンのブランチをマージするなど、ソース管理操作を実行するときに対処する競合はありません。
Podsディレクトリをチェックインするかどうかにかかわらず、PodfileとPodfile.lockは常にバージョン管理下に置かれるべきです。
ライブラリをチェックインしない開発者の集まりにいるのですが、良いコピーが別の場所にあると仮定します。したがって、私の.gitignoreには、CocoaPodに固有の以下の行を含めます。
Pods/
#Podfile.lock # changed my mind on Podfile.lock
それから私は私たちが安全な場所に図書館のコピーを持っていることを確認します。プロジェクトのコードレポジトリを使用して（コンパイルされているかどうかにかかわらず）依存関係を格納するのではなく、ビルドをアーカイブするのが最善の方法だと思います。ビルドにCIサーバー（Jenkinsなど）を使用している場合は、自分にとって重要なビルドを永久にアーカイブできます。すべてのプロダクションビルドをローカルのXcodeで行う場合は、維持する必要があるビルドすべてについて、プロジェクトのアーカイブを取る習慣を付けてください。 1.製品 - >アーカイブ
配布しています... iOS App Storeに送信します/エンタープライズまたはアドホック展開用に保存/あなたには何がありますか
プロジェクトフォルダをFinderで公開する
右クリックして "WhateverProject"を圧縮する
これにより、CocoaPodを使用しているかどうかにかかわらず、アプリのビルドに使用したプロジェクトとワークスペースの設定、バイナリ配布物（Sparkle、独自のSDK、TestFlightなど）を含むプロジェクト全体の完成イメージが得られます。
更新：これについて私の考えを変えたので、Podfile.lockをソース管理にコミットします。ただし、ポッド自体はビルドアーティファクトであるため、CIサーバーや前述のアーカイブプロセスなどの別の方法で、ソース管理外で管理する必要があります。
私のチームの誰もがいつでもソースをチェックアウトできるようにするためにPodsディレクトリとPodfileおよびPodfile.lockをコミットすることをお勧めします。
これは、必要に応じてポッドの内部のバグを修正したり、動作を変更したりしたシナリオでも役立ちますが、コミットしないと他のマシンでこれらの変更を利用できなくなります。
そして不要なディレクトリを無視するには
xcuserdata/
私は言わなければならない、私はPodsをリポジトリにコミットしているファンです。すでに述べたリンクをたどると、Podsを使用できるようにするためのiOS用のXcodeプロジェクトを立ち上げるための優れた.gitignoreファイルが得られますが、必要に応じてそれらを簡単に除外することもできます。 https://github.com/ github/gitignore/blob/master/Objective-C.gitignore
Podをリポジトリに追加することをファンにしているという私の推論は、誰も拾い上げていないような根本的な理由の1つです。私たちのプロジェクトが依存しているライブラリが突然Webから削除されたらどうなりますか？
- おそらく、ホストがGitHubアカウントを開いたままにしたくないと判断した場合ライブラリが数年前（たとえば5年以上）と言われた場合、プロジェクトがソースから利用できなくなる可能性が高いというリスクがあります。
- また、リポジトリへのURLが変わるとどうなりますか？自分のGitHubアカウントからPodにアクセスしている人が、自分自身を別のハンドルで表すことにしたとしましょう。PodsのURLが壊れてしまいます。
- 最後にもう一点。あなたが私のような開発者で、国の間を移動するときにたくさんのコーディングをするとしましょう。空港に座っている間に、私は 'master'ブランチを素早く引っ張り、そのブランチにpodをインストールして、私はみんな次の8時間のフライトに向けて準備をします。フライトに3時間かかり、別のブランチに切り替える必要があることに気付きました…。「DOH」 - 「マスター」ブランチでしか利用できないPod情報がありません。
注意...開発用の 'master'ブランチは単なる例であり、明らかにバージョン管理システムの 'master'ブランチはクリーンでデプロイ可能なものにしてください。いつでも/ buildable
これらのことから、コードリポジトリ内のスナップショットは、リポジトリサイズを厳密に制限するよりも確実に優れていると思います。そしてすでに述べたように、podfile.lockファイル - バージョン管理されている間にあなたのPodバージョンの良い歴史をあなたに与えるでしょう。
一日の終わりには、締め切りが厳しく予算が限られている場合は、時間が最も重要です。厳格なイデオロギーに時間を浪費することなく、できるだけ機知に富んでいる必要があります。 - 私たちの生活をより効率的にするため。
最後にあなたが取るアプローチはあなた次第です。
これがCocoapodsチームが考えていることです。
ワークフローはプロジェクトによって異なるため、Podsフォルダをチェックインするかどうかはあなた次第です。 Podsディレクトリはソース管理下に置き、.gitignoreに追加しないことをお勧めします。しかし、最終的にはこの決定はあなた次第です。
個人的には、 Node を使用している場合は、 node_modules のように Pods outを維持したいのですが。または Bower を使用していた場合は bower_components 。これはそこにあるほとんどすべての依存関係マネージャに当てはまり、 git submodules aswellの背後にある哲学です。
ただし、特定の依存関係の最先端のについて本当に確信を持ってほしいと思うことがあるかもしれません。そのようにしてあなたは自分のプロジェクト内で依存関係を持ち歩いています。もちろんあなたがそうするならばあてはまるいくつかの欠点があります、しかし懸念はCocoapodsだけにあてはまるというわけではありません、それらはそこにどんな依存マネージャにもあてはまります。
以下にCocoapodsチームが作成した良い pros/cons リストと、前述の引用の全文があります。
それは個人的には異なります。
ポッドが（ソース管理下の）リポジトリの一部であり、無視してはいけない理由
- 出典は同一
- （cocoapodsがなくても）そのままそのままビルドできます
- ポッドが削除されても、そのコピーが残ります（はい、これは発生する可能性があり、発生しました。小さな変更が必要な古いプロジェクトでは新しいライブラリを実装する必要がありますビルドすることさえできるようにするために）
pods.xcodeproj設定もソース管理の一部です。これは例えばプロジェクトがSwift 4にあり、まだ更新されていないためにいくつかのpodがSwift 3.2にある必要がある場合、これらの設定は保存されます。さもなければレポをクローンした人はエラーで終わるでしょう。- プロジェクトからいつでもポッドを削除して
pod installを実行することができますが、その逆はできません。 - Cocoapodの作者でも推奨しています。
いくつかの短所：より大きなリポジトリ、（主にチームメンバーのための）diffの混乱、潜在的により多くの衝突
私にとって、最大の懸念はあなたの情報源を将来的に証明することです。プロジェクトをしばらくの間存続させ、CocoaPodsがこれまでになくなったり、いずれかのポッドのソースがダウンしたりした場合、アーカイブから新しいビルドを試みるのであれば、完全に不運です。
これは定期的なフルソースアーカイブで軽減できます。
ポッドをチェックインしてください。
これはソフトウェア開発の教義であるべきだと思います
- すべてのビルドは再現可能でなければなりません
- ビルドが再現可能であることを確認する唯一の方法は、すべての依存関係を管理することです。したがって、すべての依存関係をチェックインすることは必須です。
- ゼロから始める新しい開発者はあなたのプロジェクトをチェックアウトして作業を開始することができるはずです。
どうして？
CocoaPodや他の外部ライブラリは変更されるかもしれず、それは物事を壊すかもしれません。あるいは、移動したり、名前を変更したり、完全に削除されたりする可能性があります。あなたはあなたのために物を保管するためにインターネットに頼ることはできません。あなたのラップトップは死んだかもしれませんし、修正する必要がある本番環境に重大なバグがあります。主な開発者がバスにぶつかるかもしれず、彼の交代が急いで起動しなければなりません。そして最後のものが理論的な例であってほしいのですが、実は私がいたときのスタートアップで起こったのです。 RIP。
現実的には、すべての依存関係を実際にチェックインすることはできません。ビルドの作成に使用したマシンのイメージをチェックインすることはできません。正確なバージョンのコンパイラをチェックインすることはできません。等々。現実的な限界があります。しかし、あなたができることをすべてチェックインしてください - そうしないと、単にあなたの人生が困難になります。そして私たちはそれを望んでいません。
最後の言葉：ポッドはアーティファクトを構築するものではありません。ビルド成果物は、ビルドから生成されるものです。あなたのビルドはポッドを使用します、ポッドを生成しません。なぜこれが議論されなければならないのか私にさえわかりません。
Pods/をバージョン管理にチェックインするnotの長所（主観的な重要度順）：
- はるかにコミットをマージし、コードの差分を確認するのが簡単になりました。マージはコードベースにおける問題の一般的な原因であり、これはあなたが適切なものだけに集中することを可能にします。
- 何人かのランダムな寄稿者がそれ自身で依存関係を編集してその変更をチェックすることは不可能です、そしてそれは決してするべきではありません（そしてまた差分が大きいかどうかを識別するのは難しいでしょう）。将来の
pod installが変更を隠す可能性があるため、依存関係の編集は非常に悪い習慣です。 PodfileとPods/ディレクトリの間の不一致は、チームメイトの間でより早く見つかります。Pods/をチェックインして、たとえばPodfile内のバージョンを更新するが、pod installを実行するかPods/への変更をチェックインすることを忘れた場合は、矛盾の原因に気付くのがはるかに困難になります。Pods/がチェックインされていない場合は、とにかく常にpod installを実行する必要があります。- レポサイズが小さい。小さいバイトフットプリントを持つのはいいことですが、それは壮大な計画ではあまり重要ではありません。もっと重要なこと：レポにもっとたくさんのものを持っていることはまたあなたの認知的負荷を増やします。あなたが見てはいけないということをレポに持っている理由はありません。コード（実装）ではなく、何かがどのように機能するかを知るためには、ドキュメント（抽象化）を参照してください。
- 誰かが貢献した量を識別しやすくなります（貢献したコード行には、作成しなかった依存関係が含まれないため）。
JARファイル、.venv/（仮想環境）、およびnode_modules/がバージョン管理に含まれることはありません。私たちがその質問について完全に不可知論者であったならば、notPodsをチェックインすることは先例に基づくデフォルトです。
notの短所Pods/のチェックイン
- ブランチを切り替えるとき、またはコミットを元に戻すときは
pod installを実行する必要があります。 - リポジトリを複製しただけではプロジェクトを実行できません。ポッドツールをインストールしてから
pod installを実行する必要があります。 pod installを実行するにはインターネットに接続している必要があり、ポッドのソースが利用可能である必要があります。- 依存関係の所有者がそれらのパッケージを削除した場合、あなたは問題を抱えています。
まとめると、を含まないPodsディレクトリは、より悪い習慣に対する保護策です。Podsディレクトリを含めると、プロジェクトの実行が容易になります。私は後者よりも前者を好む。そもそも間違いを犯す可能性がないのであれば、プロジェクトのすべての新しい人に「何をすべきかnot」について報告する必要はありません。私はまた、短所を軽減するPods用に別のバージョン管理をするという考えが好きです。
ワークフローはプロジェクトによって異なるため、Podsフォルダをチェックインするかどうかはあなた次第です。 Podsディレクトリはソース管理下に置き、.gitignoreに追加しないことをお勧めします。しかし、最終的にはこの決定はあなた次第です。
Podsディレクトリをチェックインする利点
- リポジトリのクローンを作成した後、CocoaPodをマシンにインストールしなくても、プロジェクトをすぐにビルドして実行できます。 pod installを実行する必要はなく、インターネット接続も必要ありません。
- Podのソース（例：GitHub）が停止したとしても、Podアーティファクト（コード/ライブラリ）は常に利用可能です。
- Podアーティファクトは、レポのクローンを作成した後の元のインストールのものと同一であることが保証されています。
Podsディレクトリを無視することの利点
- ソース管理レポジトリが小さくなり、占有スペースが少なくなります。すべてのPodのソース（GitHubなど）が利用可能である限り、CocoaPodsは通常同じインストールを再作成することができます（commit SHA = Podfile内。これは、Podfile内でZipファイルを使用するときに特に当てはまります。）
- 異なるPodバージョンのブランチをマージするなど、ソース管理操作を実行するときに対処する競合はありません。 Podsディレクトリをチェックインするかどうかにかかわらず、PodfileとPodfile.lockは常にバージョン管理下に置かれるべきです。
理論的には、Podsディレクトリを調べてください。実際には、必ずしもうまくいくとは限りません。多くのポッドはgithubファイルのサイズ制限を十分に超えているため、githubを使用している場合は、Podsディレクトリをチェックする際に問題が発生します。
これを構造化するための良い方法のように思えるのは、実際には "Pods"ディレクトリをgitサブモジュール/別のプロジェクトとして持つことです。
プロジェクトレポジトリにpodがあると、複数の開発者と作業しているときに、プル要求で非常に大きな差分が発生する可能性があります。実際の作業は、人々によって変更されています。実際のプロジェクトで変更されたものはほとんどありません）。
ライブラリを所有している人はいつでもライブラリを削除できますし、本質的にSOLなので、gitを実行することをコミットしないという問題があります。これもこれを解決します。