Ein Projekt, mehrere Kunden mit git?

Question

Im neu auf GIT und weiß nicht, noch wie viel es meine Bedürfnisse passen, aber es sieht beeindruckend.

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 Zweige zu behandeln. Jeder Kunde kann individuelle Dateien, Ordner und Einstellungen, verbesserte Versionen ... aber das sollte den gleichen ‚Kern‘ teilen. Wir sind ein kleines Team und abonnierten ein Github-Konto.

ist der Zweig den guten Weg, um diesen Fall zu behandeln?

Über die Einstellungsdatei, wie würden Sie vorgehen? Würden Sie die kundenspezifischen Einstellungsdatei .gitignore und eine settings.xml.sample Datei beispielsweise hinzufügen, ist das Repo?

Auch ist es eine Möglichkeit, einige Dateien zu verhindern, in Master zusammengeführt werden? (Aber an den Kunden Zweig verpflichtet). Zum Beispiel, wie id einige Kundendaten an den Kunden Zweig zu sparen, sondern verhindern, dass zu Meister verpflichtet werden.

Ist die .gitignore Datei branchenspezifische? YES

Bearbeiten Nach der Lektüre alle Ihre Antworten (vielen Dank!) Habe ich beschlossen, meine django Projektstruktur Refactoring zunächst den Kern und meine differents Apps in einem Unterordner Apps zu isolieren. Dadurch eine sauberere Projekt macht, und die .gitignore Datei Tweaking macht es einfach git Zweige zu verwenden, um die differents Kunden und Einstellungen zu verwalten!

Ju.

Answer 1

Neben cpharmston Antwort, es klingt wie Sie brauchen etwas Refactoring zu tun, zu trennen, was wirklich für jeden Kunden individuellen und was nicht. Dann können Sie zusätzliche Repositories Hinzufügen betrachten für jeden Client (völlig neue repos, nicht Verzweigungen) die Anpassungen zu verfolgen. Dann wird Ihr Einsatz kann Ihren „Kern“ von Ihrem Haupt-Repo, und die kundenspezifische Sachen aus diesem Repo ziehen.

Answer 2

Ich würde Zweig nicht verwenden, um zu erreichen, was Sie zu tun versuchen.

In der Quellcodeverwaltung, Niederlassungen sind für Dinge verwendet werden, die in dem Stamm zurück werden sollen zusammengeführt. Zum Beispiel Alex Gaynor seine Sommer-Code arbeitet an einem Zweig von Django, dass ermöglicht die Unterstützung für mehrere Datenbanken , mit dem Ziel, schließlich wieder in die Django Stamm verschmelzen.

Auscheckvorgänge (oder Klone , in Git Fall) könnte besser passen, was Sie versuchen machen. Sie möchten gerne ein Repo erstellen, die alle der Projektbasisdateien (und .sample Dateien, wenn man so will), und klonen den Repo an alle verschiedenen Stellen Sie den Code bereitstellen möchten. Dann manuell die Konfiguration und Anpassung von Dateien an jeder Einrichtung erstellen (darauf achtet, nicht auf hinzufügen sie an den Repo-Geschäfte). Jedes Mal, wenn Sie den Code in das Repo aktualisieren, führen Sie eine ziehen bei jedem Einsatz, den Code zu aktualisieren. Viola!

Answer 3

Matthew Talbert korrekt ist, müssen Sie wirklich das benutzerdefinierte Material von nicht-benutzerdefinierten Sachen zu trennen. Wenn Sie alle Kern-Code Refactoring kann in einem Verzeichnis enthalten sind, können Sie Ihre Kunden verwenden es als Nur-Lese-git Submodul. Der zusätzliche Vorteil ist, dass man sich in eine explizite Version des Kern-Code sperrt. Das heißt, sie müssen würde Update auf eine neuere Version bewusst, das ist, was Sie für die Produktion Code wollen.

Answer 4

Andere Antworten sind richtig, dass Sie in dem Maße, in der besten Form für die Wartung sein werden, die Sie trennen Ihre Kern-Code aus dem benutzerdefinierten pro-Client-Code. Ich werde jedoch brechen von der Masse ab und sagen, dass, wenn Sie nicht in der Lage sind, das zu tun (sagen, weil Sie zusätzliche Funktionen Kern-Code für einen bestimmten Client hinzufügen müssen), DVCS Zweige würde gut funktionieren, was Sie tun möchten, . Obwohl ich wahrscheinlich Verzweigungen pro-Verzeichnis würde empfehlen, anstatt in-Repo-Filialen für diesen Zweck (git kann auch pro-Verzeichnis Zweige tun, es ist nichts anderes als eine geklonte Repo, die abweicht).

Ich benutze hg, nicht git, aber alle meine Django-Projekte werden von der gleichen Basis „Projektvorlage“ Repo geklont, die Dienstprogramm-Skripte hat, ein grundlegender gemeinsamer Satz von INSTALLED_APPS usw. Das bedeutet, wenn ich Änderungen an dieses Projekt schablone, ich kann einfach dieses gemeinsame Updates in bestehenden Projekte zusammenführen. Dies ist nicht genau das gleiche wie das, was Sie planen, ist aber ähnlich. Sie müssen gelegentlich mit Merge Konflikten umgehen, wenn Sie die gleiche Fläche von Code im Kern ändern, die Sie bereits für einen bestimmten Client angepasst haben.

Answer 5

Nachdem alle Ihre Antworten lesen (Danke!) Ich beschloss, zuerst meine django Projektstruktur Umgestalten der Kern und meine differents Apps in einem Unterordner Apps zu isolieren. Dadurch ein sauberere Projekt macht, und die .gitignore in der differents Filialen Datei Tweaking macht es einfach git Zweige zu verwenden, um die differents Kunden und Einstellungen zu verwalten!