Ich habe Perforce schon lange verwendet, und daher mag meine Anmerkung ein wenig perforce-zentriert sein, aber die Grundprinzipien gelten für jede SCM-Software, die halbwegs ordentliche Verzweigungen aufweist. Ich bin sehr stark daran interessiert, verzweigte Entwicklungspraktiken zu verwenden. Ich habe eine "Hauptleitung" (aka "Hauptleitung"), die die Codebasis von jetzt bis zur Ewigkeit darstellt. Das Ziel ist, dass dies die meiste Zeit stabil ist und, wenn es hart auf hart kommt, könnten Sie jederzeit ein Release schneiden, das die aktuelle Funktionalität des Systems widerspiegelt. Diese nervtötenden Verkäufer fragen immer wieder ...
Entwicklungen passieren in Zweigen, die von MAIN verzweigen (normalerweise - gelegentlich möchten Sie vielleicht von einem bestehenden Dev-Zweig abzweigen). Integriere so oft wie möglich von MAIN zu deinen Dev-Zweigen, um zu verhindern, dass Dinge zu sehr auseinander gehen - oder du kannst einfach später für eine größere Integrationszeit budgetieren. Integrieren Sie nur Ihre neue Funktion "Arsch treten" zu MAIN, wenn Sie sicher sind, dass sie in einer der nächsten Versionen veröffentlicht wird.
Schließlich haben Sie eine RELEASE-Zeile, die die Option der verschiedenen Zweige für verschiedene Releases. Abhängig von den Kennzeichnungsfunktionen Ihrer SCM-Software und davon, wie unterschiedliche Haupt-/Nebenversionen wahrscheinlich sind, gibt es einige Möglichkeiten.So können Sie sich beispielsweise für einen Release-Zweig für jede Point-Release oder nur für eine Major-Rev-Nummer entscheiden. Ihre Laufleistung kann variieren.
Im Allgemeinen Zweig von MAIN, um so spät wie möglich zu veröffentlichen. Bugfixes und Änderungen in letzter Minute können entweder direkt in RELEASE für die spätere Integration in MAIN oder in MAIN für die sofortige Integrationssicherung gehen. Es gibt keine feste Regel - tue, was am besten funktioniert. Wenn Sie jedoch Änderungen haben, die an MAIN gesendet werden können (z. B. von einem Dev-Zweig oder "kleine Optimierungen" von jemandem auf MAIN), dann tun Sie den ersteren. Es hängt davon ab, wie Ihr Team arbeitet, was Ihre Freisetzungszyklen sind etc.
z. Ich würde etwas in der Art haben:
//MYPROJECT/MAIN/... - the top level folder for a complete build of all the product in main.
//MYPROJECT/DEV/ArseKickingFeature/... - a branch from MAIN where developers work.
//MYPROJECT/RELEASE/1.0/...
//MYPROJECT/RELEASE/2.0/...
Ein nicht-triviales Projekt wird wahrscheinlich eine Anzahl von DEV-Zweigen gleichzeitig aktiv haben. Wenn eine Entwicklung in MAIN integriert wurde, sodass sie nun Teil des Kernprojekts ist, kill den alten DEV-Zweig so schnell wie möglich abbrechen. Viele Entwickler behandeln einen DEV-Zweig als ihren eigenen persönlichen Bereich und verwenden ihn für verschiedene Funktionen im Laufe der Zeit wieder. Entmutigt dies.
Wenn Sie nach der Veröffentlichung einen Fehler beheben müssen, dann tun Sie das in der entsprechenden Release Branch. Wenn der Fehler zuvor in MAIN behoben wurde, dann integriere across, es sei denn, der Code hat sich in MAIN so stark geändert, dass der Fix anders ist.
Was die Codezeilen wirklich unterscheidet, sind die Richtlinien, mit denen Sie sie verwalten. Zum Beispiel, welche Tests ausgeführt werden, wer vor/nach einer Änderung reviewt, welche Aktion passiert, wenn ein Build bricht. In der Regel sind Richtlinien - und damit Overhead - in Release-Zweigen am stärksten und in DEV am schwächsten. Es gibt einen Artikel here, der einige Szenarien und Links zu anderen nützlichen Dingen durchläuft.
Schließlich empfehle ich mit einer einfachen Struktur zu starten, und nur zusätzliche dev & freigeben, wie erforderlich.
Hoffe, dass hilft, und ist nicht die Aussage-die-blutein-offensichtlich zu viel.