Ein Projekt, mehrere Kunden mit Git?

Ich bin neu bei GIT und weiß noch nicht, wie viel es meinen Bedürfnissen entspricht, aber es sieht beeindruckend aus.Ein Projekt, mehrere Kunden mit Git?

Ich habe einen einzigen Webapp, die ich für verschiedene Kunden nutze (django + JavaScript)

Ich plane GIT zu verwenden, um diese differents Kunden Version als Zweig zu behandeln. Jeder Kunde kann benutzerdefinierte Dateien, Ordner und Einstellungen, verbesserte Versionen ... aber die gleichen 'Kern' teilen. Wir sind ein kleines Team und haben einen GitHub-Account gebucht.

Ist der Zweig der richtige Weg, um mit diesem Fall umzugehen?

Über die Einstellungsdatei, wie würden Sie fortfahren? Würden Sie die kundenspezifische Einstellungsdatei bearbeiten und eine settings.xml.sample-Datei hinzufügen, zum Beispiel ist das Repo?

Gibt es auch eine Möglichkeit zu verhindern, dass einige Dateien in Master zusammengeführt werden? (aber in die Kundenfiliale verpflichtet). Zum Beispiel, ID möchte einige Kundendaten in den Kundenzweig speichern, aber verhindern, dass sie an den Master gebunden werden.

Ist die .gitignore-Datei branchenspezifisch? JA

EDIT Nachdem alle Ihre Antworten lesen (vielen Dank!) Habe ich beschlossen, meine django Projektstruktur Refactoring zunächst der Kern und meine differents Apps in einem Unterordner Apps zu isolieren. Auf diese Weise wird ein saubereres Projekt erstellt und die Optimierung der .gitignore-Datei erleichtert die Verwendung von Git-Zweigen zur Verwaltung der verschiedenen Kunden und Einstellungen.

Ju.

Quelle

2009-09-16 jujule

Zusätzlich zu cpharmstons Antwort klingt es so, als müssten Sie etwas Refactoring durchführen, um herauszufinden, was wirklich für jeden Client benutzerdefiniert ist und was nicht. Dann sollten Sie in Erwägung ziehen, zusätzliche Repositorys hinzuzufügen, um die Anpassungen für jeden Client zu verfolgen (völlig neue Repos, keine Verzweigungen). Dann kann Ihre Implementierung Ihren "Kern" aus Ihrem Hauptrepo und den kundenspezifischen Dingen aus diesem Repo ziehen.

Quelle

2009-09-16 00:46:46

Ok danke; Ich konzentriere mich heute darauf, darüber nachzudenken, Dinge zu trennen, aber das wird nicht einfach sein, da das Projekt bereits riesig ist. Also, was Sie vorschlagen, ist im Inneren eines Hauptbohrkernlager mit kundenspezifischen repos mit (schlagen Sie git Submodule?). Was ist mit Github Pseudogabeln? – jujule

git Submodule könnten funktionieren (ich habe sie nicht benutzt). Aber Sie möchten, dass es so eingerichtet ist, dass beim Auschecken Ihres Kunden-Repos das Haupt-Repo überprüft wird und nicht umgekehrt. –

@MatthewTalbert danke für die ausgezeichnete Antwort. In dem obigen Kommentar meinen Sie, dass Sie, wenn Sie das Kunden-Repo auschecken, auch Haken verwenden können, um das Basis-Repo auszuprobieren? Oder es sollte eine Art Deployment-Skript sein, das nacheinander die Repos auscheckt und den Code zusammenführt? – happyhardik

Ich würde keine Zweige verwenden, um zu erreichen, was Sie versuchen zu tun.

In der Quellcodeverwaltung sind Verzweigungen für Dinge gedacht, die zum Zusammenführen in den Verbindungsbereich gedacht sind. Zum Beispiel Alex Gaynor verbrachte seine summer of code arbeitet auf einem Zweig von Django, allows for support for multiple databases, mit dem Ziel, schließlich wieder in den Django Stamm zu verschmelzen.

Checkouts (oder clones, in Git Fall) könnte besser passen, was Sie versuchen zu tun. Sie würden ein Repo erstellen, das alle Basisdateien des Projekts (und falls gewünscht Samples-Dateien) enthält, und das Repo an alle verschiedenen Stellen klonen, an denen Sie den Code bereitstellen möchten. Erstellen Sie dann manuell die Konfigurations- und Anpassungsdateien bei jeder Bereitstellung (achten Sie darauf, dass sie nicht auf add zum Repo übertragen werden). Wenn Sie den Code im Repo aktualisieren, führen Sie bei jeder Bereitstellung eine pull aus, um den Code zu aktualisieren. Viola!

Quelle

2009-09-16 00:37:38

Dies würde im Wesentlichen bedeutet, dass sie mit vielen kritischen Dateien landen würde, die nicht unter Versionskontrolle sind. – innaM

Danke; Das einzige Problem mit diesem Setup ist, dass meine Kunden spezifische Dateien nicht in Git gespeichert werden. Und ich fühle mich nicht gut damit. – jujule

Sie können es einfach so konfigurieren, dass sich die kundenspezifischen Dateien in separaten Ordnern unter der Quellcodeverwaltung befinden. Oder Sie können sie sichern, wissen Sie, Disketten;) –

Matthew Talbert ist richtig, Sie müssen die benutzerdefinierten Sachen wirklich von nicht-benutzerdefinierten Sachen trennen. Wenn Sie den gesamten Kerncode, der in einem Verzeichnis enthalten sein soll, umgestalten können, können Ihre Clients ihn als schreibgeschütztes Git-Submodul verwenden. Der zusätzliche Vorteil besteht darin, dass Sie sie in eine explizite Version des Kerncodes sperren. Dies bedeutet, dass sie bewusst auf eine neuere Version aktualisieren müssen, was für den Produktionscode gewünscht ist.

Quelle

2009-09-16 00:50:30

Mein Projekt basiert auf einem Django, so dass es einen gemeinsamen Stammordner mit verschiedenen Dateien und Ordnern gibt. Somes sind kundenspezifisch, andere nicht. Ich muss auf Submodulen dokumentieren! – jujule

Denken Sie daran, dass Django keinen "gemeinsamen Stammordner" oder kein Projektverzeichnis benötigt. Solange Sie eine Einstellungsdatei, eine root URLconf und Ihre Apps irgendwo in Pythons sys.path importieren können, können Sie Dinge strukturieren, wie Sie es möchten. Es wäre nicht schwer, ein "Kern" -Projektverzeichnis und ein völlig separates Verzeichnis für Clientanpassungen zu haben. –

Andere Antworten sind richtig, dass Sie in dem Maße, in der besten Form für die Wartung sein werden, dass Sie Ihre Kern-Code aus dem benutzerdefinierten Code per-Client trennen. Ich werde jedoch aus der Menge herausbrechen und sagen, dass, wenn Sie das nicht können (weil Sie zum Core-Code für einen bestimmten Client zusätzliche Funktionalität hinzufügen müssen), DVCS-Zweige funktionieren gut für das, was Sie tun möchten . Obwohl ich zu diesem Zweck eher pro-verzeichnis-Verzweigungen als In-Repo-Verzweigungen empfehlen würde (git kann auch pro-verzeichnis-Verzweigungen tun, ist es nichts anderes als ein geklonter Repo, der divergiert).

Ich benutze hg, nicht git, aber alle meine Django-Projekte werden von der gleichen Basis "Projektvorlage" Repo geklont, die Dienstprogramm-Skripte, eine grundlegende gemeinsame Reihe von INSTALLED_APPS, etc. Das heißt, wenn ich Änderungen daran vornehmen Projektvorlage, kann ich diese gemeinsamen Updates leicht in bestehende Projekte zusammenführen. Dies ist nicht genau das, was Sie planen, ist aber ähnlich. Sie müssen gelegentlich mit Zusammenführungskonflikten umgehen, wenn Sie den gleichen Codebereich im Core ändern, den Sie bereits für einen bestimmten Client angepasst haben.

Quelle

2009-09-16 13:30:00

Danke, dass du deinen POV geteilt hast. Wie gehen Sie mit kundenspezifischem Code in Ihrem Django-Projekt um? benutzerdefinierte App, die eine pro-Verzeichnis-Zweig in Ihrem mercurial ist? krank auch einige Zeit dauern, die gesamte Projektstruktur – jujule

Nun, jedes Django-Projekt ist für einen bestimmten Client neu zu organisieren. Ich setze so viel Funktionalität wie möglich in wiederverwendbare Apps ein, die ich für viele verschiedene Projekte verwenden kann, nur Sachen, die mandantenspezifisch sind, gehen in das eigentliche Projektrepo. –

Nachdem alle Ihre Antworten lesen (vielen Dank!) Habe ich beschlossen, meine django Projektstruktur Refactoring zunächst der Kern und meine differents Apps in einem Unterordner Apps zu isolieren. Dies macht ein saubereres Projekt, und das Anpassen des .gitignore in der Datei differents branches macht es einfach, git branches zu verwenden, um die verschiedenen Kunden und Einstellungen zu verwalten!

Quelle

2009-09-17 08:09:53 jujule

Antwort

Verwandte Themen