ローカル マシンに grails アプリケーションがあり、XP-DEV にリポジトリを作成しました。フォルダーが.groovyあり.settings、プロジェクトルートにあります。これらのファイルをバージョン管理にコミットする必要がありますか? これらのフォルダの用途がわからないため、この質問をしています。
質問する
1076 次
3 に答える
10
アップデート
5年以上の開発経験があり、少し元の意見に戻る必要があると思います。一般に、これらのファイルはソース管理に含めるべきではないと私は今でも考えています。
ただし、開発者間で共有すると便利な特定の設定があります。問題は、どの設定を共有し、どの設定を共有しないかを判断するのが非常に難しいことです。たとえば、絶対パスを含む設定は共有しないでください。しかし、特定のツールの構成 (Eclipse、IntelliJ など) に絶対パスが含まれているかどうかはどうすればわかりますか?
バージョン管理に git を使用している場合、github.gitignoreはさまざまなツールgithub/gitignoreの多くのテンプレートを公開しています。設定を共有してみたい場合は、これらのテンプレートのいずれかを使用することをお勧めします。
これらのテンプレートが機能しない場合は、これらの設定をバージョン管理にチェックインせず、自動的に生成できるようにするという最初の推奨事項を支持します。次に、共有する重要な設定 (コード スタイル テンプレートなど) がある場合は、予想されるすべての開発環境にその設定を適用する方法について説明します。
元の回答:
.settings通常、使用しているIDEによって作成され（Eclipseがこの規則を使用していることは知っています）、IDEに関するプロジェクト固有の設定が含まれています。
.groovygroovy のユーザー固有の設定が含まれています。たとえば、Grape が依存関係を .groovy ディレクトリにダウンロードすることは知っています。
私の意見では、これらのディレクトリをコミットしないでください。他の人があなたのプロジェクトをチェックアウトすると、これらのディレクトリの個人用コピーが自動的に生成されます。
于 2012-08-09T13:40:00.067 に答える
9
@FGregからの回答に同意しません。.settingsフォルダーには、プロジェクト固有の設定が含まれています。これには、カスタムコンパイラ設定、エラーと警告レベル、フォーマット設定、保存アクションなどが含まれます。一般に、これらの設定を開発者間で共有することをお勧めします。これらの設定が共有されていない場合、フォーマットの不整合やコンパイラの問題が発生する可能性があります。
一般に、チームに一貫した開発環境が必要な場合は、設定フォルダーをバージョン管理に含める必要があります。
Groovy-Eclipse内の.groovyフォルダーは、プロジェクト固有のDSL情報と推論の提案に使用されます。一般に、プロジェクト固有の推論情報がある場合は、同じプロジェクトの他のユーザーとこれを共有することをお勧めします。
私たちのチームでは、各プロジェクトで使用されるすべての設定を明確に定義し、.settingsフォルダーをコミットし、すべての開発者に同じ設定が表示されることを保証します。
于 2012-08-10T04:54:02.943 に答える
2
私の謙虚な意見では、IDE プロジェクト ファイルをコミットするのは悪い考えです。実行する特定の構成がある場合は、maven、gradle、ant などを構成して、正しい構成を生成する必要があります。
私が見た問題のリストがあります
- プロジェクトはおそらく IDE 固有のものです。
- 開発と統合には違いがあります。後で問題を検出します。
- IDE の構成ファイルは、IDE のバージョンとインストールされているプラグインによって異なります。
- 人々は間違いを犯します (それが私たちがソース管理を行う理由です) 一部のファイルは間違った構成でコミットされます。
このファイルをコミットすることを選択した場合は、正しいファイルが確実にコミットされるように手動で余分な作業を行う必要があることに注意してください。しかし、ビルド ツールを正しく構成すれば、作業は 1 回だけで済みます。;)
于 2012-08-15T12:45:34.760 に答える