GIt Workflow Entwicklung und Produktion - wo soll ich die Repos erstellen?

Question

Ich habe irgendwo gelesen * ein Setup wie dieses wäre schön:

Zwei Hauptzweige, einer für jeden Server.

Wenn Sie auf Master drücken, werden Änderungen live übertragen;

Wenn Sie auf dev / stage (oder wie auch immer Sie es nennen) drücken, werden Änderungen an das Staging gesendet;

Workflow:

• Zweig von dev erstellen;

• arbeiten Sie vor Ort, bis Sie zum Testen bereit sind;

• merge zurück zu dev;

• push-to-Hub, der Änderungen an den Entwicklungs- / Staging-Server sendet.

Sobald Sie mit diesen bereit sind, live zu gehen:

• merge vom Entwickler zum Master,

• schieben Sie dann den Master zum Hub, der diese Änderungen an den Live-Server sendet.

Zwei Hauptzweige, einer für jeden Server.

Also habe ich einen Zweig "Produktion" auf "webroot / myliveapp /" und ein weiterer Zweig "Entwicklung" auf "webroot / devapp /"

Wo soll das Repository sein?

UPDATE:

Ich meine:

Wir werden nach diesem Fluss haben:

• Primäres Repo;

• Nackter Repo-Hub;

• Klonen;

Die Entwicklungs- und Produktionszweige sollten zu einem Repository gehören, oder?

Wenn dies korrekt ist, sollten wir dann den ERSTEN git init Befehl git init ?Auf unser Prime Repo ?

Also werden wir haben:

"webroot / myliveapp /" - Produktionszweig;

"webroot/devapp/" - Entwicklungszweig;

"webroot/.git" - Primäres Repository;

Macht das Sinn?

Oder sollte das Hauptlager unserem Produktionsstandort entsprechen?

*Beachten:wenn Sie einen Kontext darüber benötigen, welchen Workflow ich implementieren möchte, ist dies der folgende:http://joemaller.com/990/a-web-focused-git-workflow/

Answer 1

Danke für das Update zu deiner Frage, es ist jetzt klarer.

Ich glaube, das Problem, das Sie haben, beruht auf einem Missverständnis des Git-Workflows;Git ist nicht gleichzusetzen Directory zu Zweigen entspricht es a ansicht Ihres Dateisystems verzweigen.Das ist mächtig - aber leicht, sich selbst in den Fuß zu schießen.Lass es mich erklären.

Git verhält sich eher wie ein datenbankgestütztes, differentiell versioniertes Dateisystem zur Verlaufsverfolgung an sich.Es befindet sich "über" Ihrem Dateisystem, nicht "Teil davon".Es verwendet Ihr Dateisystem nicht, um Zweige darzustellen, sondern wenn Sie einen anderen Zweig auschecken, alle Dateien in Ihrem Dateisystem werden in die Dateien in diesem Zweig geändert.Sie bitten Git, Ihr Dateisystem dazu zu bringen, die alternative Realität dieses Zweigs darzustellen.

Wenn Sie in der Filiale sind master, und es hat eine Datei root/foo.txt committed, und Sie checken Branch aus experiment, was tut nicht haben root/foo.txt verpflichtet, finden Sie diese Datei vorbei wenn du danach suchst.Es ist ein Teil von master, nicht experiment, und so ist es nicht in Ihrem Dateisystem vorhanden.Aus diesem Grund ist Git sehr wählerisch, wenn es darum geht, dass Ihr aktueller Zweig festgeschrieben wird, bevor Sie Zweige wechseln können - wenn Sie Änderungen an Ihrem Dateisystem vorgenommen haben, von denen Git nichts weiß, weigert es sich, sie wegzublasen, indem es sie mit einer anderen Realität überschreibt.Sie müssen eingreifen, um die Dinge zuerst richtig zu machen.

Um die Frage zu beantworten, erstellen Sie keine Unterverzeichnisse für "myliveapp" und "devapp" - erstellen Sie verschiedene Zweig.Haben Sie einfach Ihre eine Codebasis unter "webroot".Hacken Sie dann beispielsweise den Zweig "instabil" ab und übernehmen Sie Ihre Änderungen wie gewohnt.Sie können dann alle Dateien in Ihrem Repository auf die Version der Dateien Ihres Entwicklungsservers umstellen, indem Sie zum Zweig "devapp" wechseln, und Sie können auf ähnliche Weise jederzeit wieder zu "unstable" wechseln.

Wenn Sie einen Zweig aktualisieren möchten, z.wenn Sie ein Update Ihres Entwicklungsservers durchführen, können Sie merge "instabil" in "devapp".Dadurch werden alle Dateien von "devapp" wie die von "unstable" aussehen und auf den neuesten Stand gebracht.

Eine andere Sache zu beachten:der Unterschied zwischen einem Prime Repo, einem Bare Repo und Klonen ist fast gleich Null.Es gibt praktisch keinen Unterschied in der Software;vielmehr ist es eine menschliche Konvention zu sagen "Linus 'Kernel ist der kanonische Linux-Kernel".Mit diesem Verständnis:

• Ein Prime Repo ist nur ein Repository, in dem sich alle einig sind, dass es die "kanonische" Version der Software enthält.Das heißt, wenn ein Entwickler eine Änderung vorgenommen hat, die jeder sehen soll, anstatt zu sagen: "Ziehen Sie meine Version von devapp", können sie sagen: "Ich habe meine Änderungen in unserem Prime Repo veröffentlicht." Es ist einfach eine einfache Konvention, auf der sich die Leute versammeln können.
• Ein Klon ist eine Kopie eines anderen Repos.Ich könnte das Prime Repo klonen, Änderungen vornehmen und dann können Sie mein Repo klonen.Wenn Sie Änderungen vornehmen, können Sie diese entweder auf das Prime Repo oder auf meins übertragen, solange die Zusammenführung gültig ist und Sie über Berechtigungen auf dem Computer verfügen.
• Ein nacktes Repository hat einfach keine "Arbeitskopie" - es gibt kein "Webroot" -Verzeichnis auf diesem Computer.Es ist leer mit nur der .git verzeichnis - was für Server in Ordnung ist, auf denen niemand die Dateien ändern muss.

Schließlich wird die .git dir enthält nicht die Dateien Ihres Repos, sondern die Git-Konfiguration und die Datenbank.Es ist Ihr gesamter Repository-Verlauf in Datenbankform, der verwendet wird, um den Rest des Repos mit einer bestimmten Version Ihrer Software zu füllen.Deshalb habe ich den Kommentar gemacht:sie können lokal Auschecken jede Version einer alternativen Realität des Repositorys, ohne Netzwerkkommunikation, zu jeder Zeit - weil es alles da ist in der .git dir.Die einzige Netzwerkkommunikation, die erforderlich ist, ist, wenn Sie möchten Sync ihr lokales Repository zu einem anderen Repository, mit push oder pull.