Frage

Das Projekt ist mit Maven so die POM-Dateien die Hauptquellen der Projektinformation sind. Es gibt einige nützliche Einstellungen in den Projektdateien, die schön wäre, zu halten.

OTOH Idee scheint zu viele redundante Änderungen in der Projektdatei Struktur zu schaffen, die die SVN-Geschichte verpestet und manchmal schafft Konflikte.

Sollte ich das .idea Verzeichnis und die * .iml Dateien unter Versionskontrolle? vollständig? teil?

Update: So ist die beste Praxis, die ich für mich gearbeitet haben gefunden und mein Team ist so weit:

  1. Überprüfen Sie in allen IDEA-Dateien, * .iml und .idea Verzeichnisse. Sie enthalten wertvolle Informationen und es ist eine Verschwendung von Zeit, es jedes Mal neu erstellen Sie aktualisieren.
  2. Erstellen Private Branch für jeden Entwickler
  3. cd in .idea Verzeichnis
  4. svn schalten Sie es zu seinem privaten Zweig Gegenstück
  5. Sie in IDEA Dateien auf regelmäßige Commits nicht überprüfen - sie Geschichte verschmutzen. Überprüfen Sie sie in auf speziellen Commits.

Auf diese Weise halten Sie den Inhalt .idea Verzeichnis in der Versionskontrolle aber halten Sie es von der Art und Weise der regelmäßigen Commits aus. Jeder Entwickler kann jemand anderen Zugriff auf IDEA Verzeichnisse hat.

Update 2: Da diese Frage geschrieben wurde, habe ich meine Praxis auf nicht Überprüfung in allen IntelliJ Dateien in die Versionskontrolle geändert, wie sie von vielen Responder beraten. Dies ist meine derzeitige Praxis sowohl für Maven und Gradle. Die Werkzeuge haben zu dem Punkt entwickelt, die kritischen Informationen finden Sie stets von der ursprünglichen .POM oder .gradle Dateien wiedergegeben werden. Wenn die Dateien ändern, verfolgt die IDE Änderungen zuverlässig, so dass Sie Ihre IDE-Dateien nicht verlieren, die oft so gibt es keine Notwendigkeit, sie zu lesen ist.

Update 3: 7 Jahre nach der diese Frage scheint es immer noch relevant. Das gleiche bewährte Verfahren zu Gradle gilt auch (wahrscheinlich SBT auch.): Nicht überprüft IDE-Dateien in, erstellen Sie sie bei Bedarf aus dem Grunde POM, .gradle oder SBT-Dateien

War es hilfreich?

Lösung

Kurze Antwort: nicht setzen diese Dateien im Quellcodeverwaltungsrepository wie Sie können „erzeugen“, um sie (und dies gilt umso mehr, wenn Sie sie nicht brauchen, wenn sie lästig sind, wenn sie andere Umgebung brechen ).

ich persönlich die folgenden Werte für svn:ignore verwenden:

target 
*~ 
*.log 
.classpath 
.project 
*.ipr 
*.iws 
*.iml 
.settings 

Andere Tipps

Einer der großen Vorteile von Maven ist, dass der Werkzeugträger besteht ein POM in einem nativen Projekt in Eclipse, Idee und Netbeans für das Drehen. Wenn Sie einen pom haben, können Sie ein native Projekt ziemlich schnell erstellen.

Aus diesem Grunde würde ich prüfen, nicht in .idea oder * .iml Dateien unter Quellcodeverwaltung mehr, als ich in RMI Stubs oder Klassendateien überprüfen würde.

Ich glaube, Sie .idea Verzeichnis in der Versionskontrolle setzen sollten. Der größte Teil der Konfiguration enthalten sollte Version verfolgt werden, z.B. Compiler configs.

Die einzige Datei, die Versionskontrolle gehört nicht ist .idea / workspace.xml, weil es nur die entsprechenden Konfigurations insbesondere auf Ihrer lokalen Umgebung.

IntelliJ Idea setzt tatsächlich workspace.xml in Ignore-Liste standardmäßig, also wenn Sie Idee verwenden, um zu überprüfen, sollten Sie alle eingestellt werden, ohne etwas zu ändern.

Ich sehe, dass die Standard-Antwort „nicht überprüfen in der Projektdatei, sondern nur die .pom“. Aber Dinge wie die .ipr Dateien enthalten viele nützliche Einstellungen, die nicht aus dem .pom Datei abgeleitet werden. Was passiert, wenn Kolleginnen und IntelliJ Benutzer diese Einstellungen teilen möchten? Ich weiß, dass .ipr Dateien ausgelegt sind (siehe diesen Thread zum Beispiel) werden versioniert. Ich wünschte, ich hätte eine tatsächliche Antwort, aber ich habe noch nicht eine gute Praxis zu diesem Thema gefunden.

Meine Meinung ist, dass wir keine IDE bestimmte Dateien aus der Versionskontrolle behalten sollte. Die Idee ist, dass wir so viel wie möglich Informationen in IDE unabhängiger Form wie Maven pom-Dateien und so weiter halten sollen. Alle kritischen Projekteinstellungen können dort gehalten werden. Und alle wichtigen Projekteinstellungen in pom-Datei gehalten, die ich sehe keinen ernsthaften Grund nicht nur in IDEA Projektkonfiguration zu überprüfen, aber jede andere IDE spezifische Konfiguration. Zusätzlich verpestet .idea Ordner Stil Projektkonfiguration wirklich changeset Protokolle. Und wir wollen noch IDEA Projekteinstellungen in der Versionskontrolle halten, können wir zumindest speichern sie in einzelnen .ipr Dateiformat.

Ich bin zu dieser Party zu spät, aber genau dieses Problem hat mich plagen. Und ich war einfach begeistert mit dem, was ich arbeite glauben könnte, zumindest mit unserem Quellkontrollsystem.

Die IntelliJ Dateien müssen nicht gespeichert werden „zusammen“ mit dem autoritativen pom.xml und der Quelle. Die Versionskontrolle Geschichte ist nicht „verschmutzt“, wenn jene nicht-Quellen in Zusammenhang stehenden Änderungen an einem anderen Ort im Quellbaum aufgezeichnet werden.

Also habe ich versucht, um die IntelliJ-Dateien auf einen parallel in dem Versionskontrollsystem zu bewegen, verwenden Sie eine einfache Datei / Verzeichniszuordnung Quell- und Projektdateien auf dem Entwickler-Maschine wieder zu vereinigen und überwachen Änderungen in dem Versionskontrollsystem, das rein sind Dateien, die die Build.

beeinflussen
Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top