web-dev-qa-db-ja.com

Xcodeプロジェクトファイルのマージ

ブランチをマージするとき（私はgitを使用しています）、Xcodeプロジェクトファイル（Project.xcodeproj/project.pbxproj）で競合が発生することがよくあります。簡単な場合もありますが、プロジェクトファイルが壊れて元に戻す必要がある場合があります。最悪の場合、ファイルをドラッグするなどして、2番目のコミット（以前のコミットとつぶすことができる）でプロジェクトファイルを手動で修正する必要があります。

Xcodeプロジェクトファイルのような大きくて複雑なファイルのマージ競合を処理するためのヒントは誰にもありますか？

EDIT-いくつかの関連する質問：

Gitおよびpbxproj

merge = unionを使用して.pbxprojファイルをgitとマージする必要がありますか？

リソース：

http://www.alphaworks.ibm.com/tech/xmldiffmerge

http://www2.informatik.hu-berlin.de/~obecker/XSLT/#merge

http://tdm.berlios.de/3dm/doc/thesis.pdf

http://www.cs.hut.fi/~ctl/3dm/

http://el4j.svn.sourceforge.net/viewvc/el4j/trunk/el4j/framework/modules/xml_merge/

objective-cxmlxcodegitversion-control
33
Felixyz

  1. プロジェクトをより小さく、より論理的なライブラリ/パッケージに分割します。大規模なプロジェクトは、オブジェクトの処理が多すぎたり、大きすぎたりするなど、定期的に悪いデザインの兆候です。

  2. 簡単に再構築できるように設計する-これは、複数のツールまたはIDEで構築する必要があるプログラムを作成している場合にも役立ちます。私の「プロジェクト」の多くは、1つのディレクトリを追加することで再構築できます。

  3. 無関係なビルドフェーズを削除します。例：すべてのプロジェクトから「ヘッダーのコピー」ビルドフェーズを削除しました。 includeディレクティブを使用して、特定のファイルを明示的に含めます。

  4. 可能な限りxcconfigファイルを使用してください。これにより、ビルドの更新時に行う必要がある変更の数も削減されます。 xcconfigファイルは、ビルド設定のコレクションを定義し、#includeをサポートします。もちろん、使用するxcconfigを定義するときに、各プロジェクトとターゲットから（大部分の）ユーザー定義設定を削除します。

  5. ターゲットの依存関係の場合：物理操作ではなく論理操作を実行するターゲットを作成します。これは通常、シェルスクリプトターゲットまたは集約ターゲットです。例：「ビルドの依存関係」、「すべての単体テストを実行」、「すべてをビルド」、「すべてをクリーン」。そうすれば、方法のすべてのステップですべての依存関係の変更を維持する必要がなくなります。これは、参照を使用するようなものです。

  6. コードに共通の「ソースツリー」を定義し、サードパーティのソースに2番目を定義します。

  7. 利用可能な外部ビルドツールがあります。これは（少なくとも一部のターゲットでは）オプションの場合があります。

この時点で、xcodeprojははるかに単純になります。必要な変更が少なく、再構築が非常に簡単です。これらの概念をさらに活用して、プロジェクトとビルドの複雑さをさらに減らすことができます。

8
justin

あなたは試してみたいかもしれません https://github.com/simonwagner/mergepbx/

これは、Xcodeプロジェクトファイルを正しくマージするのに役立つスクリプトです。まだアルファ版であることに注意してください。

免責事項：私はmergepbxの作成者です。

3
Simon

2つのXcodeプロジェクトを比較するには、FileMergeを開きます（xcodeを開き、Xcodeを選択します（マニュウィンドウから）->開発者ツールを開く-> FileMerge）。 「左」ボタンをクリックして、xcodeプロジェクトのメインディレクトリを開きます。 「右」ボタンをクリックし、xcodeプロジェクトのメインディレクトリを開いて比較します。

「マージ」ボタンをクリックしてください！

それでおしまい！

2
evya

私が見つけた最善の方法は、.pbxprojファイルをバイナリとして扱うようにGitに指示することです。これは乱雑なマージを防ぎます。

これを.gitatributesファイルに追加します。

*.pbxproj -crlf -diff -merge
2
radven

問題を経験する回数を減らすのに役立つかもしれない考慮すべき別のオプション。説明のために、チームメンバーのブランチが「開発」ブランチからのものであることをブランチと呼びます。チームで、プロジェクトファイルが変更されると、変更内容（ビルドの整合性を保証するために必要な他の変更と共に）が別のコミットでコミットされるという規則を設けます。そのコミットは、developブランチに選択されます。ブランチでプロジェクトファイルを変更することを計画している他のチームメンバーは、ブランチを選択するか、最新の開発に基づいてブランチをリベースできます。このアプローチには、チーム全体でのコミュニケーションといくつかの規律が必要です。言ったように、それは常に可能であるとは限りません。いくつかのプロジェクトではそれが大いに役立つかもしれません、そしていくつかのプロジェクトではそれは役に立たないかもしれません。

0
Martin Lockett