Einstellungen

Sauberer und einfacher Entwicklungszyklus für extrem stabile Lieferungen

Haben Sie gelesen Wie Sie Github zur Verwaltung Ihrer Entwicklung nutzen Wenn ja, oder wenn Sie git-scm bereits kennen, finden Sie hier einen sehr einfachen und sauberen Entwicklungszyklus, dem Sie bei der Arbeit in unserem Netzwerk folgen können.

Die Ausgangslage

Ihr Kunde bittet um die Entwicklung einer neuen Funktion, eines Hotfixes, eines Problems oder um die Überarbeitung der gesamten Website? Was auch immer die Anfrage ist, Sie werden immer den gleichen Weg gehen

Erstellen Sie Ihren eigenen Zweig

Auf Ihrer Entwicklungsumgebung werden Sie mit der neuesten Haupt Übertragen und einen eigenen Zweig erstellen #dev_Abzweigung# davon

git checkout main # reset the branch if necessary
git pull origin main
git checkout -b #dev_branch#
git push origin #dev_branch#

Jetzt können Sie mit der Arbeit an Ihrem Zweig beginnen.

WICHTIGER HINWEIS
Solange Sie Ihre erste Lieferung für die Produktion noch nicht abgeschlossen haben NIEMALS git pull origin main in Ihrer Filiale.
So können wir Ihre Code-Probleme von den Problemen bei der Zusammenführung mit dem Haupt Zweig, sobald wir Ihre Entwicklung in prod pushen müssen. (mehr dazu später im Artikel)

Lieferung für UAT

Sobald Sie bereit sind, Ihre Arbeit in die Produktion zu überführen, legen Sie sie dem Kunden zum User Acceptance Testing (UAT) vor.
Dieser Schritt und die Validierung direkt vom Kunden sind erforderlich, bevor wir den Push in die Produktion übernehmen.

Was passiert in dieser Phase?

  1. Wir setzen UAT mit der neuesten Hauptumgebung zurück
  2. Wir ziehen Ihren Zweig auf den UAT-Zweig*
  3. Wir prüfen, ob es Konflikte gibt oder nicht

* Der folgende Screenshot dient als Beispiel, diese Art von Commit wird nie in das Repo gepusht, wenn das aus irgendeinem Grund der Fall wäre, würde diese Art von Commit auf UAT Zweigstelle zu einem bestimmten Zeitpunkt

Fall 1 - Ohne Konflikt

Wenn es eine kein Konflikt & der Kunde hat den Push zur Produktion validiert

  1. Wir ziehen Ihren Zweig in main und übergeben ihn an repo.

Fall 2 - Mit Konflikten

Wenn es gibt einen Konflikt

  1. Wir bitten Sie git pull origin main in Ihrer Branche den Konflikt zu lösen
  2. Ihr Angebot für UAT einreichen

Wenn es keinen Konflikt mehr gibt (der Konflikt wurde behoben) und der Kunde hat den Push für die Produktion bestätigt

  1. Wir ziehen Ihren Zweig in main und übergeben ihn an repo - das würde dann so aussehen

Beispiel eines Konflikts

Wenn wir Sie gebeten haben, den Produktionszweig mit Ihrem Zweig zusammenzuführen, werden Sie git pull origin main auf Ihrem Zweig, der Ihnen das gleiche Ergebnis wie bei UAT zeigt. Diese Konflikte werden aufgelistet als ein Ergebnis von Git-Pull Ausgabe

user@server ~/public_html (uat)
$ git pull origin dev-lifecycle
Von https://github.com/owner/repo.git
 * Zweig dev-lifecycle -> FETCH_HEAD
Automatische Zusammenführung von conflictingfile.txt
CONFLICT (Inhalt): Zusammenführen eines Konflikts in conflictingfile.txt
Automatisches Zusammenführen fehlgeschlagen; Konflikte beheben und dann das Ergebnis übertragen.

Dann müssen Sie nur noch den Konflikt beheben, der in unserem Fall wie folgt aussah

Von

An

Zusammenfassend

Ziehen Sie niemals den Hauptzweig in Ihren, außer wenn wir Sie darum bitten 🙂
Wir hoffen, dass dieses Thema Ihnen mehr Klarheit darüber verschafft, wie Sie Ihre Dev-Filialen in unserem Netzwerk bearbeiten können.