Wir haben ein großes Rails-Projekt, das auf einem Produktions- und Staging-Server ausgeführt wird. Es ist eine gute Idee, jedes Mal Tags zu erstellen, wenn wir sie für die Bereitstellung oder Produktion bereitstellen (dies würde automatisch mit capistrano geschehen). Oder ist es besser, Verzweigungen namens "Devlopment" und "Staging" zu erstellen (Master würde den Produktionsstatus enthalten)?
Sie können Zweige für die Entwicklung, Bereitstellung und Produktion verwenden und gleichzeitig Tags zur Identifizierung von Produktionsversionen verwenden. Ich mag die Art und Weise, wie git flow mit diesen Zweigen umgeht und es Ihnen ermöglicht, mehr Zweige für die Entwicklung zu verwenden Neue Eigenschaften. Als Entwickler müssten Sie niemals Code in den Master-Zweig schreiben, und auch das Zusammenführen in den Master ist selten.
Tags in git sind ziemlich langlebig: Sie propagieren automatisch beim Abrufen aus einem Remote-Repository, und wenn Sie sie bereinigen möchten, müssen Sie dies manuell in jeder Kopie tun. Daher würde ich lieber Zweige (und möglicherweise ihre Reflogs) für die Markierung der automatischen Bereitstellung verwenden, da ich sonst wahrscheinlich bald in vielen Tags vergraben würde.
Wir kennzeichnen jeden unserer Bereitstellungen (automatisch in unseren Bereitstellungsskripts), um bei Bedarf eine schnelle Wiederherstellung zu ermöglichen, aber sie sind auch als Deployment-Verlauf praktisch. Zum Beispiel:
%Vor%Sie können festlegen, dass Ihr Skript Tags nur für die letzten N Bereitstellungen beibehält, wenn Sie eine große Anzahl von Tags vermeiden möchten.
Eine Verzweigung macht mehr Sinn, wenn Ihre Bereitstellungsart zum Beispiel in einem Produktionszweig zusammengeführt wird, auf dem ein Git-Hook einen Pull auf dem Prod-Server auslöst.
Tags und Links git branch deployment capistrano tags