Sind Teilbäume der Workflow, den ich suche?

Question

Ich versuche einen Workflow für den Wechsel zwischen verschiedenen Arbeitsumgebungen in einem Projekt einzurichten. Alle diese drei Bereiche sind ihre eigenen separaten Ordner (sie sind Websites) und ich möchte in der Lage sein, auf der Entwicklungszeitachse zu arbeiten, bis ich für QA-Tests bereit bin, und dann meine Version auf eine QA-Zeitachse schieben. Sobald die QS fertig ist, möchte ich das zur allgemeinen Verwendung in Produktion bringen. Alle Zeitleisten haben ihren eigenen separaten Ordner, da es sich um Websites handelt. Ich habe ein Bild in Visio gezeichnet, um den Workflow zu illustrieren, den ich in meinem Kopf habe. Benutzt ich Unterbäume, nach denen ich suche? oder gibt es einen besseren Weg, dies zu tun? Vielen Dank! Hinweis: Ich führe Windows Server 2012 R2, IIS 8 mit, Entwicklung, Test und Produktion ihre eigenen einzigartigen Websites jetzt mit ihrer eigenen Datenbankserverinstanz und FTP-Server.

Answer 1

Nur meine Erfahrung aus einer sehr kleinen Team Perspektive zu teilen. Unsere Produktions- und Testumgebung befindet sich im selben Hauptzweig, jedoch getrennt nach Branchenname (Master, qc) und Tag (master.01.date, qc.01.date usw.). Wir machen eine Menge von Rebase/Cherry-Pick/Merge-Dev-Commits zum Hauptzweig und veröffentlichen diese entsprechend auf Websites (QC/Produktion).

Dev A und B abzweigen irgendwo auf aktuellen oder früheren Produktions begehen.

Dev A getan, rebased zu Hauptzweig, veröffentlichen zu QC-Site und senden an QC-Team.

Dies funktioniert möglicherweise nicht für größere Team oder komplizieren Projekt. Aber das ist für uns einfach zu verstehen. Ich wünsche, dass wir Commits vor dem Zusammenführen zerquetschen, wir haben zu viele Commits imo, aber sie sind leichter zu verfolgen.

Answer 2

Sie könnten einfach separate Filialen im Repo verwenden und jeden Ordner den Repo klonen und den entsprechenden Zweig auschecken. Dadurch können Sie ganz einfach zusammenführen und verzweigen, je nach Bedarf (abhängig davon, wie die Historie aussehen soll oder nicht); von dem, was Sie beschrieben haben, möchten Sie ohne Rebasing fusionieren, denn dann haben Sie nur einen Commit, wie "mergen" QA in Produktion "statt alle QA-Commits einzufangen". Dies erfordert einen geringen Aufwand durch das .git-Verzeichnis in jedem Ordner, aber es scheint die Bequemlichkeit wert.

Es besteht auch die Möglichkeit, die falsche Verzweigung in einem Ordner auszuprobieren. Wenn Sie sich darüber Sorgen machen, können Sie stattdessen jeden Ordner zu einem eigenen, leeren (oder meist leeren) Repo machen, das Ihren eigentlichen Code als Submodul enthält. Dadurch können Sie den Ordner für einen bestimmten Commit (und damit für eine Verzweigung) sperren. Zum Beispiel könnten Sie nach dem Zusammenführen der QA in den Produktionszweig die Bindung des Produktionsreports an das Submodul für diesen neuen Commit vorrücken.

Es ist wahrscheinlich am besten, das Rosinenpicken zu vermeiden, da dies alle möglichen seltsamen Probleme verursachen kann und die Geschichte schwieriger zu folgen macht.