Hier ist die Beschreibung meiner täglichen Arbeit:
Zwei Entwickler arbeiten in vielen kleinen Features oder Fixes, sagen wir 3-4 pro Tag für jeden Entwickler. Ich muss in der Lage sein, gleichzeitig an den Funktionen A - B - C zu arbeiten, während mein Kollege an den Funktionen D und E arbeitet.
Montag : Feature A wird an einen Staging-Server zur Überprüfung des Clients weitergeleitet. Feature B wird für die Clientüberprüfung an denselben Staging-Server gesendet. Feature D wird zur Kundenüberprüfung an denselben Staging-Server gesendet.
Dienstag : Wir erhalten die Zustimmung des Kunden für A und D (aber nicht für B). Und sie müssen sofort mit diesen Änderungen leben.
Mittwoch : Feature C wird für die Clientüberprüfung an denselben Staging-Server gesendet. Genehmigung für B wird schließlich erhalten.
Donnerstag : Feature B muss sofort in Produktion gehen.
Freitag : In der letzten Produktionsversion wurde ein Fehler entdeckt, und wir müssen zur vorherigen Version zurückkehren.
Dies kann nicht als Scrum-ähnlicher Prozess behandelt werden, da es keine Möglichkeit gibt, Features in Stories oder Sprint-Planung zu gruppieren. Dies ist mehr wie ein Wartungsprozess (vielleicht Kanban?).
Können Sie ein Beispiel dafür geben, wie Sie das mit Git handhaben würden? Nehmen wir an, dass wir im Moment nur einen Master-Zweig haben und wann immer wir etwas zur Inszenierung oder Produktion bringen wollen, müssen wir "git pull" machen, um alle Änderungen live zu machen (sogar die unerwünschten). Was ist mit git "cherry-pick", um bestimmte Commits abzurufen? Ein Zweig pro Feature scheint zu beschwerlich zu sein, da wir zu viele Features haben. Wenn Sie bestimmte Beispiele für Git-Befehle und Verzweigungen (nur um die Hauptidee zu zeigen, müssen nicht 100% korrekt sein) wäre das großartig.
Danke.
Ich entschied mich schließlich für die folgende Vorgehensweise:
Ein lokaler Zweig für die Produktion.
git checkout -b staging #on staging server
git checkout -b production #on production server
Programmierer A muss an einem Feature / Patch A arbeiten:
%Vor%Das Gleiche gilt für Programmierer B, der an Feature B arbeitet.
Produziert werden:
%Vor%Außerdem kann der lokale Produktionszweig so gesteuert werden, dass er es beherrscht, wenn Änderungen aktiv sind und genehmigt werden:
%Vor%Das ist, was in unserer Situation am besten funktioniert hat, hoffe, es hilft jemandem.
Nach dem, was Sie beschrieben haben, würde ich eine Strategie eines Freisetzungszweiges und vieler Arbeitszweige übernehmen.
Bedeutung: Sie sollten Ihren Staging-Server so einrichten, dass er nur aus dem Zweig staging zieht, während Sie und Ihre Mitarbeiter alle an Ihren eigenen Feature-Zweigen arbeiten (A, B, C und vielleicht Master)
Wenn eine Änderung live geschaltet werden soll, fügen Sie die Funktion einfach in den Zweig staging ein und schieben sie auf den Server - das Staging-Env zieht dann diesen Zweig und stellt ihn bereit.
Sobald Sie die Genehmigung von Ihrem Client erhalten haben, können Sie den Feature-Zweig (der bereits in staging eingebunden war) in einen anderen Zweig (vielleicht stable ) schieben und dann zur Produktion bereitstellen.
Sobald Sie in Produktion sind, können Sie den Feature-Zweig löschen und von vorne beginnen.
TLDR: Behandeln Sie jede Ihrer Umgebungen als Zweig, der nur verschoben wird, wenn ein Feature dorthin gehen muss. Auf diese Weise können Sie sogar Änderungen von Zweigen / Umgebungen wiederherstellen, die nicht dorthin gehen sollen.
Und ich würde mit einem Kanban-Ansatz gehen - einfacher und für das, was Sie zu tun scheinen, besser geeignet.
Wir haben git flow für solche Szenarien verwendet.
Da der Git-Flow es Ihnen ermöglicht, mehrere Features zu erstellen und nur die gewünschten zu den Entwicklungs- und Master-Zweigen zu verschieben, sollte es sich gut an Ihre Anforderungen anpassen.
Hier sind einige Links für git-flow:
Ссылка http://yakiloo.com/getting-started-git-flow/
Ich habe git-flow so angepasst: Ссылка
Der große Unterschied ist, dass Sie alle Features vom selben Start für einen Sprint / Iteration starten.