Wie gehe ich mit IntelliJ IDEA-Projektdateien unter Git-Quellcodeverwaltung um, die sich ständig ändern?


151

Jeder in unserem Team verwendet IntelliJ IDEA, und wir finden es nützlich, die Projektdateien (.ipr und .iml) in die Quellcodeverwaltung zu integrieren, damit wir Build-Konfigurationen, Einstellungen und Inspektionen gemeinsam nutzen können. Außerdem können wir diese Inspektionseinstellungen auf unserem Continuous Integration Server mit TeamCity verwenden. (Wir haben die .iws-Datei für den Arbeitsbereich pro Benutzer in der .gitignore-Datei und nicht in der Quellcodeverwaltung.)

Diese Dateien ändern sich jedoch geringfügig, wenn Sie in IDEA so gut wie alles tun. Es gibt ein Problem in der IDEA-Problemdatenbank ( IDEA-64312 ). Vielleicht könnte man dies als Fehler in IDEA betrachten, aber es ist eines, mit dem wir auf absehbare Zeit leben müssen.

Bis vor kurzem haben wir Subversion verwendet, aber kürzlich sind wir zu Git gewechselt. Wir hatten uns gerade daran gewöhnt, eine Änderungsliste mit Projektdateien zu haben, die wir ignorierten und nicht eincheckten, es sei denn, es gab Änderungen an Projektdateien, die wir mit anderen teilen wollten. Aber mit Git scheint die wahre Stärke (von dem, was wir untersuchen) die kontinuierliche Verzweigung zu sein, die es fördert, und das Wechseln zwischen Verzweigungen ist ein Schmerz, da die Projektdateien immer geändert wurden. Oft kann es die Änderungen einfach irgendwie zusammenführen und versucht, mit den Änderungen der Projektdatei umzugehen, die jetzt auf den neuen Zweig angewendet werden. Wenn der neue Zweig jedoch Projektdateien geändert hat (z. B. wenn der Zweig an einem neuen Modul arbeitet, das sich noch nicht in den anderen Zweigen befindet), gibt git nur einen Fehler aus, der nicht angezeigt wird. ' Es macht keinen Sinn, in den Dateien zusammenzuführen, wenn sowohl der Zweig Änderungen aufweist als auch Sie Änderungen lokal haben, und ich kann den Punkt eher verstehen. Über die Befehlszeile kann man "-f" für den Befehl "git checkout" verwenden, um zu erzwingen, dass die lokalen Änderungen verworfen werden und stattdessen die Verzweigungen verwendet werden. (1) Der Befehl "Git Checkout GUI" in IDEA (10.5.1) scheint dies nicht als Option zu haben, die wir finden können, daher müssten wir regelmäßig zur Befehlszeile wechseln, und (2) wir sind uns nicht sicher, ob wir es uns zur Gewohnheit machen wollen kennzeichnen und Git anweisen, unsere lokalen Änderungen wegzuwerfen.

Hier sind einige Gedanken zu Optionen, mit denen wir uns befassen müssen:

  1. Nehmen Sie die Projektdateien vollständig aus der Quellcodeverwaltung. Legen Sie sie in den .gitignore und verteilen Sie sie auf andere Weise an jede Person und TeamCity, indem Sie sie möglicherweise an einer anderen Stelle oder unter anderen Namen in die Quellcodeverwaltung einfügen. Unser Team ist klein genug, um diese Option in Betracht zu ziehen, aber sie scheint nicht großartig zu sein.
  2. Lebe weiter damit und versuche sicherzustellen, dass du sicher bist, welche Dateien wir zu einem bestimmten Zeitpunkt in welchen Zweigen haben. Als Teil davon können wir jedem Entwickler empfehlen, mehr als eine Kopie jedes Projekts auf seinem System zu haben, damit jeder in einem anderen Zweig mit möglicherweise unterschiedlichen Sätzen von Projektdateien ausgecheckt werden kann.
  3. Versuchen Sie, nur das Projekt (.ipr) in der Quellcodeverwaltung zu haben, wobei die Moduldateien (.iml) nicht in der Quellcodeverwaltung und in der .gitignore-Datei enthalten sind. Die Hauptsache, die sich in der .ipr-Datei regelmäßig von selbst zu ändern scheint, ist die Reihenfolge der gemeinsam genutzten Build-Konfigurationen, aber vielleicht können wir die Informationen darüber, wie diese eingerichtet werden, einfach separat teilen. Ich bin mir nicht ganz sicher, wie IDEA mit so etwas umgeht, wenn es nur einige seiner Dateien hat, insbesondere bei einer neuen Kasse.

Ich hoffe, es gibt eine offensichtliche (oder nicht offensichtliche) Lösung, die wir verpasst haben, vielleicht die enorme Anpassbarkeit, die Git und IDEA beide zu haben scheinen. Aber es scheint, als könnten wir unmöglich das einzige Team sein, das dieses Problem hat. Zu den Fragen, die bei Stack Overflow ähnlich sind , gehören 3495191 , 1000512 und 3873872 , aber ich weiß nicht, da sie genau dasselbe Problem sind, und vielleicht kann sich jemand die Vor- und Nachteile für die verschiedenen Ansätze ausdenken , die ich habe skizzierte Ansätze, die in den Antworten auf diese Fragen aufgeführt sind, oder Ansätze, die sie empfehlen.



Antwort unten angegeben gitignore.io als gute Basis. Ich fand es nützlich, auch wenn drei Jahre später: gitignore.io/api/java,android,eclipse,intellij
WernerCD

Beachten Sie, dass das von mir erwähnte IDEA-Problem youtrack.jetbrains.com/issue/IDEA-64312 in IntelliJ IDEA 14 als behoben markiert ist, sodass diejenigen, die die neueste Version verwenden und die Dateien in der Quellcodeverwaltung behalten möchten, möglicherweise jetzt eine bessere Zeit dafür haben als zu der Zeit, als ich diese Frage gestellt habe.

Antworten:


48

Sie können die verzeichnisbasierte Projektstruktur von IDEA verwenden , bei der die Einstellungen im IDE-Verzeichnis anstelle der IPR-Datei gespeichert werden. Es bietet eine genauere Kontrolle darüber, was in der Versionskontrolle gespeichert ist. Die IML-Dateien sind weiterhin vorhanden, sodass die zufälligen Änderungen in ihnen nicht gelöst werden (möglicherweise außerhalb der Quellcodeverwaltung?), Aber das Teilen von Dingen wie Codestil und Inspektionsprofilen ist einfach, da jede von ihnen vorhanden sein wird in einer eigenen Datei unter dem Verzeichnis .idea.


Der Wechsel zur verzeichnisbasierten Struktur hat definitiv sehr geholfen. Wir haben die IML-Dateien aus der Quellcodeverwaltung entfernt, was IDEA beim ersten Auschecken ein wenig verwirrt, aber es scheint der beste Kompromiss für den Moment zu sein. Wir mussten auch die TeamCity-Inspektionen aus der Maven-Datei und einem exportierten Inspektionsprofil herausarbeiten lassen, aber das hat auch funktioniert. Danke dir!

Die Verbindung ist unterbrochen. Ich bin mir nicht sicher, was der ursprüngliche Inhalt war, aber hier ist ein Link zu einem relevanten Dokument zur Projektstruktur von IDEA. Und hier ist ein weiterer Link, der sich mit diesem speziellen Thema befasst.
Ben.12

31

Aus dem offiziellen DOC: http://devnet.jetbrains.com/docs/DOC-1186

Abhängig vom IntelliJ IDEA-Projektformat (.ipr-Datei oder .idea-Verzeichnis) sollten Sie die folgenden IntelliJ IDEA-Projektdateien unter die Versionskontrolle stellen:

.ipr dateibasiertes Format

Geben Sie die .ipr-Datei des Projekts und alle .iml-Moduldateien frei. Geben Sie die .iws-Datei nicht frei, da sie benutzerspezifische Einstellungen speichert.

.idea verzeichnisbasiertes Format

Geben Sie alle Dateien im Verzeichnis .idea im Projektstamm frei, mit Ausnahme der Dateien workspace.xml und task.xml, in denen benutzerspezifische Einstellungen gespeichert sind. Geben Sie auch alle .iml-Moduldateien frei.

Ich habe es in meinen .gitignore gelegt:

#Project
workspace.xml
tasks.xml

8
Ja, und wie ich in der Frage sagte, teilten wir die .ipr und .iml und nicht die .iws. Das Problem ist das Problem in youtrack.jetbrains.com/issue/IDEA-64312, dass sich die IML-Dateien ständig ändern, was zu häufigen Konflikten führt. Die .iml-Dateien außerhalb der Quellcodeverwaltung zu halten, scheint für uns besser zu funktionieren, da IDEA sie aus dem Maven POM neu generiert und sie dann einfach lokal ohne Konflikte mit anderen Entwicklern ändern können. Vielen Dank!

Bei diesem Ansatz haben wir Probleme mit einigen Ressourcennamen, zum Beispiel: Android JDK-Versionen. Einige Mitglieder unseres Teams haben unterschiedliche Namen oder Versionen für ein konfiguriertes SDK. Wenn Sie Projektdateien zum Repo senden, müssen Sie diese Dinge mit Ihrem Team in Einklang bringen. Bis gestern waren wir nicht daran gewöhnt, Projektdateien an Repo zu senden, aber es wurde schwierig, weil unser Projekt groß und schwer zu konfigurieren wurde.
Felipe

Die Vereinheitlichung gebrauchter SDKs und relativer Pfade ist die einfache und effektive Lösung
Kumait

1
Ja. Jetzt zeigen alle unsere Module auf "Project SDK" und wir richten uns mit dem Team aus, um dasselbe SDK zu verwenden. Zumindest ist nur ein Ort zum Ändern. Aber IntelliJ könnte es besser machen.
Felipe

23

Eine offizielle Antwort ist verfügbar . Angenommen, Sie verwenden das moderne (und jetzt standardmäßige) .ideaOrdnerprojektformat:

  • Alles hinzufügen ...
  • Außer .idea/workspace.xml(was benutzerspezifisch ist)
  • Außer .idea/tasks.xml(was benutzerspezifisch ist)
  • Mit Ausnahme einiger anderer Dateien, die möglicherweise Passwörter / Schlüssel / usw. enthalten (Details siehe oben)

Diese .gitignore-Beispieldatei ist möglicherweise eine nützliche Referenz. Sie sollten jedoch den obigen Link lesen, um zu verstehen, warum diese Einträge angezeigt werden, und um zu entscheiden, ob Sie sie benötigen.

Persönlich ignoriere ich die .idea/find.xmlDatei auch, da sich dies jedes Mal zu ändern scheint, wenn Sie einen Suchvorgang ausführen.


1
Basierend auf dem Link "Beispiel-Gitignore-Datei" würde ich noch einen Schritt weiter gehen und bin froh, dass Sie dies angegeben haben. Gehen Sie zur Basisadresse und Sie können verschiedene Typen kombinieren, um einen "vollständigen" Gitignore zu erhalten. Für mein Android-Projekt, das offensichtlich Java, Android, Eclipse, IntelliJ verwendet: gitignore.io/api/java,android,eclipse,intellij
WernerCD

16

Ich habe workspace.xml aus der Quellcodeverwaltung entfernt (+ zu .gitignore hinzugefügt).


10

Unser Team checkt keine pfadspezifischen IntelliJ-Dateien ein. Wir gehen davon aus, dass die Benutzer die IDE verwenden und ein Projekt einrichten können. IntelliJ-Dateien werden in die Änderungsliste "Ignoriert" aufgenommen.

AKTUALISIEREN:

Die Antwort ist jetzt einfacher, da ich Maven und seine Standardverzeichnisstruktur verwende.

IntelliJ sollten alle Dateien in ignorieren gefragt werden /.svn, /.ideaund /targetOrdner. Alles, was sich auf die Pfadinformationen einer Person bezieht, wird in gespeichert /.idea.

Alles andere ist faires Spiel, um sich Subversion oder Git zu widmen.


14
Das Einrichten des Projekts ist keine große Sache, da es nicht oft vorkommt, aber es ist sehr praktisch, Build-Konfigurationen und Inspektionsprofile gemeinsam nutzen zu können, ohne Screenshots oder ähnliches per E-Mail versenden zu müssen.

1
Checken Sie die Dinge ein, die nicht vom Pfad einer Person abhängen.
Duffymo

2

Nur um einen anderen Ansatz zu teilen, den mein Team verwendet hat: Verschieben Sie einfach alle IDE-bezogenen Dateien an einen anderen Speicherort, den IntelliJ nicht erkennt, und erstellen Sie ein Skript, um sie an den gewünschten 'aktiven' Speicherort zu kopieren, der von GIT ignoriert wird.

Der Vorteil dieses Ansatzes besteht darin, dass Sie die Option beibehalten haben, IDE-Einstellungen über die Versionskontrolle freizugeben. Der einzige Nachteil besteht darin, dass Sie entscheiden müssen, wann das Skript ausgeführt werden soll (wahrscheinlich einmal pro Arbeitsbereich-Klon oder wenn Änderungen gewünscht werden), und Sie können dies automatisieren, indem Sie das Skript in Ihren Erstellungsprozess oder Post-Merge-Hook integrieren.

Dieser Ansatz basiert darauf, dass IntelliJ nur bestimmte Speicherorte nach seinen Einstellungsdateien durchsucht, sodass er auch für Framework-Konfigurationsdateien gilt. Tatsächlich haben wir die Grails .properties-Datei auf die gleiche Weise ignoriert, damit Entwickler ihre lokalen Konfigurationsänderungen nicht versehentlich einchecken.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.