Was soll ich aus IDE-Projekten in mein Repository aufnehmen?

10

Ich möchte ein Projekt hinzufügen, das in diesem Fall in Netbeans erstellt wird, aber diese Frage ist für die meisten IDEs allgemein. Es ist einfach, was ich in mein Repository aufnehmen soll. Zum Beispiel erstellt Netbeans einen Ordner nbproject, Eclipse erstellt einen Ordner .settings usw. Sollte ich diese in mein Repository aufnehmen, welche Vor- und Nachteile hat das Einschließen oder Nichteinschließen projektspezifischer Einstellungen?

In diesem Fall handelt es sich um ein persönliches Projekt, daher kann ich mir nicht vorstellen, dass andere Leute damit beginnen, daran zu arbeiten. Es wäre jedoch schön, ein Minimum an Projekteinstellungen hinzuzufügen, damit das Projekt selbst problemlos auf verschiedenen Computern arbeiten kann.

— Daniel Figueroa
quelle

Ziehen Sie Tools wie maven mit seinem Eclipse-Plugin (oder einer anderen Idee) in Betracht , um die richtige Umgebung einzurichten, anstatt Ihre eigene einzuschließen .

@MichaelT Es tut mir sehr leid, aber ich folge nicht wirklich. Würde es Ihnen etwas ausmachen, das zu erweitern?

— Daniel Figueroa

Wenn Sie ein Build-Tool verwenden und das Build-Tool die Umgebung für das ide einrichten, können Sie sicher sein, dass das Setup unabhängig von der Plattform (oder ide) identisch ist. Selbst Solo-Entwickler haben mehrere Umgebungen (ide vs build). Dies vereinfacht die Frage zu einer Frage, die beantwortet wird: "Checken Sie nichts ein, das für Ihre Umgebung spezifisch ist, da es sich um generierten Code handelt." - das gleiche Rationale, das Sie nicht in den von jaxb generierten .java-Klassen einchecken, sondern in den Anweisungen (build.xml oder .pom-Datei), wie sie erstellt werden.

Wenn es "original" ist, muss es gesichert werden. Wenn es sich ändert und diese nachverfolgt werden müssen und original sind, sollte es revisionskontrolliert werden. Der Haken - wie Sie Ihr Repo so strukturieren, dass Ihre Quelle Ihre Quelle bleibt, während Ihre Toolkettenkonfigurationen das Quell-Repo nicht verschmutzen. Gleiches gilt für Ressourcen wie Bilder, Ton und Video ....

— Mattnz

4

Es hängt wirklich davon ab, um welche Daten es sich handelt, und sollte von Fall zu Fall entschieden werden, möglicherweise sogar für einzelne Dateien. Schauen Sie sich den Inhalt dieser Dateien an. Meistens kann man sagen, was sie bedeuten. Dinge wie die Position und Größe der IDE-Fenster möchten Sie in der Quellcodeverwaltung nicht.

Einige der IDE-Projektdateien sind jedoch wichtige Projektmetadaten. Ich kenne Netbeans nicht gut, aber für Eclipse teilt die .project-Datei der IDE mit, wie das Projekt heißt, dass es sich um ein Java-Webprojekt usw. handelt, und die .classpath-Datei enthält Informationen zu Quellordnern und -bibliotheken. Einige Dateien im Verzeichnis .settings können gleich wichtig sein, z. B. enthält org.eclipse.core.resources.prefs Informationen darüber, welche Codierung für welche Dateien verwendet werden soll.

Als Projektmetadaten verdient dieses Zeug eine Versionierung in der Quellcodeverwaltung.

Einige IDEs können Projektmetadaten von anderen IDEs importieren. Es wäre sogar noch besser, es in einer Form zu haben, die nicht an eine bestimmte IDE gebunden ist.

Für Java gibt es so etwas: Maven . Es legt strenge Konventionen für die Projektstruktur fest und ermöglicht es Ihnen, Projektmetadaten (z. B. Bibliotheksabhängigkeiten) an einem Punkt anzugeben (eine Datei namens pom.xml, die sich im Hauptverzeichnis des Projekts und natürlich in der Quellcodeverwaltung befindet). Es gibt Plugins, die dann IDE-Projektdateien aus der Maven-Konfiguration erstellen, und andere, die den Projekterstellungsprozess automatisieren oder so gut wie alles tun können. Manchmal fühlt es sich so an, als würde es die Dinge unnötig komplex machen und das Lernen dauert einige Zeit, aber die Vorteile sind es im Allgemeinen wert.

— Michael Borgwardt
quelle

1

Wenn ich mich nicht irre, ist Maven IDE-unabhängig. Wenn ja, dann sollte es, da es Projekteinstellungen / Metadaten enthält, definitiv in das Repo aufgenommen werden, aber nicht die "IDE-Projektdateien", auf die sich OP speziell zu beziehen scheint.

— Bleeding Fingers

@ hus787: Mein Punkt ist, dass diese Metadaten sehr wichtig genug sind, um im Repo zu sein, und während es großartig ist, wenn Sie es in einer IDE-unabhängigen Form haben, ist es immer noch besser, es zu haben, als es nicht zu tun, wenn dies nicht der Fall ist habe es.

— Michael Borgwardt

2

Dies hängt wirklich davon ab, welche Art von Informationen Sie im Repository haben möchten. Wenn Sie möchten, dass alles bis zu den Dateien funktioniert, die Sie zum Zeitpunkt des Commits geöffnet und bearbeitet haben, und Sie der einzige sind, der das Repository verwendet, schreiben Sie alles fest, wissen Sie jedoch, dass es möglicherweise nicht auf einem anderen Computer funktioniert .

Wenn Sie Ihren Code für andere Personen freigeben möchten, die möglicherweise nicht dieselbe IDE verwenden, schreiben Sie den Code selbst ohne projektspezifische Implementierung fest.

Wenn Sie wissen, dass jeder dieselbe IDE verwendet, können Sie wahrscheinlich alles einschließen, was nicht rechnerspezifisch ist, dh alle Einstellungsdateien / -ordner nur für die IDE selbst. Auf diese Weise können sie das Projekt bereits als das importieren IDE erwartet es.

— Ampt
quelle

2

Artefakte, die Ihrer Entwicklung helfen und für den Build / Release oder das Projekt selbst nicht von Nutzen sind, sollten nicht enthalten sein. Das Repo sollte sauber und ordentlich sein und nur die Dinge enthalten, die für das Projekt relevant sind, nicht Ihre Umgebung . Das Repo sollte Ihre Gewohnheiten nicht kennen. Und zweitens wird es Sie unnötig nerven, wenn Sie etwas Ähnliches tun git status... aber hey, ich habe nie Änderungen vorgenommen ... ahh, ignorieren Sie das.

Lassen Sie mich ein praktischeres Beispiel geben (ich werde es githier als Werkzeug verwenden):

Sie möchten niemals, dass ein (rekursives) Submodul in Ihrem Haupt-Repo ein IDE-spezifisches Material enthält (dies kann auch die Hauptprojektumgebung beeinträchtigen), da Sie sich nur um den Code kümmern, der von jemand anderem (oder Ihnen) geschrieben wurde und ist der Verwendung innerhalb des aktuellen Projekts. Nicht die Umgebung, in der es entwickelt wurde. Sie wollen das wahrscheinlich auch nicht jemand anderem antun.

Um Ihre Einstellungen auf verschiedenen Computern verwenden zu können, empfehle ich, in Ihrer IDE zu stöbern und zu prüfen, welche Unterstützung sie für solche Dinge bietet. Emacs hat initund Emacs Server auch. Oder Sie können ein benutzerdefiniertes Makro oder Skript ( .sh) erstellen, das das Setup automatisch ausführt.

— Blutende Finger
quelle

-1: stimme überhaupt nicht zu. Dies können sehr wichtige und nützliche Informationen sein, und Ihr Repo sollte auf jeden Fall solche Informationen enthalten.

— Michael Borgwardt

@MichaelBorgwardt Was ist, wenn OP später plant, zu einer anderen IDE zu wechseln? Wie werden diese projekt-IDE-spezifischen Einstellungen in der anderen verstanden? Ein Beispiel wäre sehr dankbar.

— Bleeding Fingers

Einige IDEs können Projektmetadaten von anderen IDEs importieren. Selbst wenn dies nicht möglich ist, sind diese Dateien normalerweise etwas von Menschen lesbar und es ist besser, sie zu haben, als sie nicht zu haben.

— Michael Borgwardt

Und was passiert, wenn Sie Ihren Arbeitsbereich vollständig überladen haben (was mir kürzlich passiert ist) und die Änderungen nicht rückgängig machen können, indem Sie die Dinge manuell so zurücksetzen, wie Sie es vorher gedacht haben? Ich habe mir wahrscheinlich Stunden gespart, weil der Arbeitsbereich eingecheckt wurde. Ganz zu schweigen davon, dass der Arbeitsbereich in einigen IDEs Dinge wie Codevorlagen enthält, die jedes Mal manuell eingerichtet werden müssten.

— Amy Blankenship

@AmyBlankenship, das ist mein Punkt, es ist Ihr Arbeitsbereich. Wie können Sie sicher sein, dass es andere nicht stört (sie ziehen und plötzlich wird ihr Arbeitsbereich durch Ihren ersetzt)? Es ist besser, diese Dinge in einer separaten lokalen Niederlassung zu halten oder Sie können mercurial für Ihren persönlichen projektspezifischen Arbeitsbereich VC und git für das Projekt VC verwenden. In Bezug auf die Codevorlagen denke ich, dass Ihre IDE nicht ausgereift genug ist (oder noch nicht richtig untersucht wurde). Wenn Sie sagen, dass die Vorlagen projektspezifisch sind, sollten Sie nach Mustern in Ihrem Code suchen.

— Blutende Finger

1

Wenn es sich um ein persönliches Projekt handelt, speichere ich die Einstellungen in der Quellcodeverwaltung. Persönlich tötet nichts meine Motivation für ein Projekt mehr als das erneute Einrichten einer Entwicklungsumgebung.

Wenn mehr Leute involviert sind, setze ich diese Dinge nicht in die Quellcodeverwaltung ein. In meinem Team wird eine Mischung aus IntelliJ, Sublime Text und Eclipse verwendet. IDE-Dateien sorgen nur für Unordnung und führen dazu, dass Commits für eine IDE, die Sie nicht verwenden, von anderen Personen auf diese Dateien übertragen werden.

Außerdem sollte Ihr Projekt sowieso nicht von der IDE abhängig sein. Ein Build-Server startet Eclipse nicht, um Ihr Produkt zu kompilieren. Daher sollte es bereits IDE-frei sein. Ein kleinerer Punkt: Es beseitigt die persönliche Organisation innerhalb des Projekts. Zum Beispiel verwende ich in IntelliJ gerne viele Module in unserem Projekt. Niemand, der IntelliJ verwendet, macht sich darüber Sorgen, da wir die IML-Dateien (Moduldateien) nicht speichern.

Wenn Ihr Team dieselbe IDE verwendet, ist es besser, aber dann schreibt jemand einen fehlerhaften .classpath-Eintrag fest, weil er einen absoluten Pfad verwendet hat. Jetzt macht sich jeder, der die IDE verwendet, Sorgen.

Sicher, der Nachteil ist, dass es mehr Setup gibt, wenn jemand das Projekt auscheckt. Ich denke es lohnt sich. Wir verwenden Ivy für das Abhängigkeitsmanagement und verfügen über Informationen zu Einrichtung, Abhängigkeiten usw. Trotz dieser Vorabkosten halte ich es für sinnvoll, die IDE-Einstellungen außerhalb der Quellcodeverwaltung zu halten.

— Kryptisch
quelle