web-dev-qa-db-ja.com

Gitソース管理下でIntelliJ IDEAプロジェクトファイルを常に変更する方法

チームの全員がIntelliJ IDEAを使用しており、プロジェクトファイル（.iprおよび.iml）をソース管理に入れて、ビルド構成、設定、および検査を共有できると便利です。さらに、TeamCityとの継続的統合サーバーでこれらの検査設定を使用できます。 （ユーザーごとのワークスペース.iwsファイルは、ソース管理ではなく.gitignoreファイルにあります。）

ただし、IDEAで何かを行うと、これらのファイルはほとんど変化しません。 IDEAの問題データベースには問題があります（ IDEA-64312 ）。したがって、これはIDEAのバグと考えられるかもしれませんが、近い将来に対応する必要があるものです。

最近まで、Subversionを使用していましたが、最近Gitに切り替えました。プロジェクトファイルの変更リストを持っていることに慣れてしまったので、他の人と共有したいプロジェクトファイルの変更がない限り、無視してチェックインしませんでした。しかし、Gitの本当の力は、（私たちが探求しているものから）それが奨励する継続的な分岐であると思われ、分岐の切り替えはプロジェクトファイルが常に変更されているため苦痛です。多くの場合、何とかして変更をマージするだけで、新しいブランチに現在適用されているプロジェクトファイルの変更を処理しようとします。ただし、新しいブランチがプロジェクトファイルを変更した場合（ブランチが他のブランチにまだない新しいモジュールで動作している場合など）、gitはファイルにマージしても意味がないというエラーをスローしますブランチに変更があり、ローカルに変更がある場合、そのポイントを理解できます。コマンドラインから、「git checkout」コマンドで「-f」を使用してローカルの変更を破棄し、代わりにブランチを使用することができますが、（1）IDEAのGit Checkout GUIコマンド_（10.5.1）は、見つけることができるオプションとしてそれを持たないようです。そのため、定期的にコマンドラインに切り替える必要があります。そのフラグを使用して、ローカルの変更を破棄するようにGitに指示する習慣があります。

そのため、これに対処しなければならないオプションに関して考えていることを以下に示します。

  1. プロジェクトファイルをソース管理から完全に削除します。それらを.gitignoreに配置し、他の何らかの方法でソース管理に配置するか、または他の名前でそれらを各人とTeamCityに配布します。私たちのチームはこのオプションは十分に小さいので、検討するのに十分実行可能ですが、素晴らしいとは思えません。
  2. 特定の時間にどのブランチにどのファイルがあるかを確実に管理するように努めてください。この一環として、各開発者がシステム上に各プロジェクトのコピーを複数持つことをお勧めします。これにより、プロジェクトファイルのセットが異なる可能性がある異なるブランチにそれぞれチェックアウトすることができます。
  3. モジュール（.iml）ファイルをソース管理と.gitignoreファイルに含めずに、プロジェクト（.ipr）のみをソース管理に入れてみてください。 .iprで定期的に独自に切り替わると思われる主なことは、共有ビルド構成の順序ですが、それらの設定方法に関する情報を個別に共有することもできます。 IDEAが、特に新しいチェックアウトで、ファイルの一部のみを持つというこの種の問題をどのように処理するのかはよくわかりません。

おそらく、GitとIDEAの両方が持っていると思われる巨大なカスタマイズ可能性に対処する、私たちが見逃したいくつかの明白な（または非自明な）ソリューションがあることを望んでいると思います。しかし、この問題を抱えているチームは私たちだけではないようです。 StackOverflowで似たような質問には、 495191 、 1000512 、および 873872 がありますが、まったく同じであるためわかりません私が概説したさまざまなアプローチ、それらの質問への回答にリストされているアプローチ、または彼らが推奨するアプローチの長所と短所を誰かが思いつくかもしれません。

ありがとうございました。

gitversion-controlintellij-idea
145
Peter Cooper Jr.

IDEAの ディレクトリベースのプロジェクト構造 を使用できます。設定は.iprファイルではなく.ideaディレクトリに保存されます。バージョン管理に保存されているものよりも多くの 詳細な制御 を提供します。 .imlファイルは引き続き存在するため、それらのランダムな変更は解決しません（ソース管理の対象から外しますか？）が、コードスタイルや検査プロファイルなどを共有するのは簡単です。 .ideaディレクトリの下の独自のファイル内。

46
Esko Luontola

公式DOCから： http://devnet.jetbrains.com/docs/DOC-1186

IntelliJ IDEAプロジェクト形式（.iprファイルベースまたは.ideaディレクトリベース）に応じて、次のIntelliJ IDEAプロジェクトファイルをバージョン管理下に置く必要があります。

.iprファイルベースの形式

プロジェクトの.iprファイルとすべての.imlモジュールファイルを共有します。ユーザー固有の設定が保存されるため、.iwsファイルは共有しないでください。

.ideaディレクトリベースの形式

ユーザー固有の設定を保存するworkspace.xmlおよびtasks.xmlファイルを除く、プロジェクトルートの.ideaディレクトリの下にあるすべてのファイルを共有し、すべての.imlモジュールファイルも共有します。

私はそれを私の.gitignoreに入れます：

#Project
workspace.xml
tasks.xml
30
Felipe

公式の回答が利用可能 。最新の（そして現在デフォルトの）.ideaフォルダープロジェクト形式を使用していると仮定します。

  • すべて追加...
  • .idea/workspace.xml（ユーザー固有）を除く
  • .idea/tasks.xml（ユーザー固有）を除く
  • パスワード/キー/などを含む可能性のある他のファイルを除きます（詳細については上記のリンクを参照）

この sample .gitignore file は参考になるかもしれませんが、これらのエントリが表示される理由を理解し、必要かどうかを判断するには上記のリンクを読む必要があります。

個人的には、.idea/find.xmlファイルも無視します。これは、検索操作を実行するたびに変更されるようだからです。

23
Drew Noakes

Workspace.xmlをソース管理から外しました（+ .gitignoreに追加）。

16
ripper234

私たちのチームは、パス固有のIntelliJファイルをチェックインしません。 IDEの使用方法とプロジェクトのセットアップ方法を知っていると想定しています。 IntelliJファイルは「無視」変更リストに追加されます。

更新：

Mavenとそのデフォルトのディレクトリ構造を使用しているので、答えは簡単になりました。

IntelliJは、/.svn、/.idea、および/targetフォルダー内のすべてのファイルを無視するように求められる必要があります。個人のパス情報に関連するすべてのものは、/.ideaに保存されます。

それ以外はすべてSubversionまたはGitにコミットするのに公平なゲームです。

10
duffymo

私のチームが使用した別のアプローチを共有するために：IDE関連ファイルをIntelliJが認識しない別の場所に移動し、無視される「アクティブな」場所にコピーするスクリプトを作成するギット。

このアプローチの利点は、バージョン管理を通じてIDE設定を共有するオプションを保持したことです。唯一の欠点は、スクリプトを実行するタイミング（おそらくワークスペースクローンごとに1回または変更が必要な場合）を決定する必要があり、ビルドプロセスまたはマージ後フックにスクリプトを組み込むことでこれを自動化できることです。

このアプローチは、IntelliJが設定ファイルの特定の場所のみを検索することに依存しているため、フレームワーク構成ファイルにも適用されます。実際、Grailsの.propertiesファイルを同じ方法で無視したため、開発者がローカルの構成変更を誤ってチェックインすることはありません。

2
Shawn