Das ABC des Branching und Merging - Crossroads 2009

Resources / ALM

36 views
0 Likes
0 0
Branching ist sowohl einfach als auch komplex – und für viele bleibt es ein Buch mit sieben Siegeln. Dieser Artikel benennt die Gründe für branching, erläutert dessen Konzepte und beschreibt verschiedene branching/merging-Strategien, um dem Leser eine solide Basis in diesem Themenbereich zu vermitteln.

Die Veröffentlichung der deutschen Übersetzung des Originalartikels erfolgt unter freundlicher Genehmigung von Mario Moreira.

Share on Social Networks

Share Link

Use permanent link to share in social media

Share with a friend

Please login to send this document by email!

Embed in your website

Select page to start with

1. CM Paper Das ABC des Branching und Merging Schlüsselkonzepte Branching/ Merging - Strategie Und m ehr

6. © 2009 elego Software Solutions GmbH www.elego.de – Phone: +49 30 2345 8696 6 / 9 neuen Projektentwicklungen (zu project branches , integration branches , site branches und private branches ) eingebracht werden, so dass die Korrekturen in neuen releases ebenfalls vorhanden sind und keine Re gression de r Funktionalität und Stabilität vorkommt. Abbildung 2 zeigt ein Beispiel eines branching / merging - Modells, welches einige der oben aufge führten branch - Typen verwendet. Abbildung 2: Beispiel eines branching/merging - Modells Erarbeiten einer Branching/Me rging - Strategie Beim Erarbeiten einer branching / merging - Strategie ist es wichtig zu verstehen, dass sich die bran ching - Anforderungen einer bestimmten Anwendung weiterentwickeln werden. Eine heute angemesse ne Strategie wird in Zukunft nicht unbedingt ausr eichend sein. Deshalb ist es wichtig, sich bei der Defi nition einer branching - Strategie sowohl über den kurz - als auch den langfristigen branching - Bedarf ei ner Anwendung Gedanken zu machen. Dazu gehören drei Aspekte: Komplexität über Zeit, Aufwand und In stabilitätsrisiko. Sind diese in Betracht gezogen, lässt sich ein branching / merging - Modell erstel len, das die Produktentwicklung unterstützen kann. Komplexität über Zeit Wie komplex ist die Entwicklung des Produkts und wie komplex könnte sie in Zukunft we rden? Einige Schlüsselkonzepte der Komplexität einer branching - Strategie sind: Die Anzahl der beteiligten Nutzer Die Art der Nutzer, die beteiligt sind (Entwickler, Tester, Build/Release Engineers , etc.) Das voraussichtliche Ausmaß an paralleler Entwicklun g (Anzahl der parallel laufenden relea ses und der Korrekturen vergangener releases , ob mehrere Standorte beteiligt sind und wie oft Prototypen getestet werden sollen)

9. © 2009 elego Software Solutions GmbH www.elego.de – Phone: +49 30 2345 8696 9 / 9 Referenzen 1. „ ABCs of a Branching and Merging Strategy “ von Mario Moreira, © 2003 CM Crossroads o „Software Configuration Management Patterns: Effective Teamwork, Practical Integration“ von Stephen P. Ber czuk mit Brad Appleton, 2003, Addison Wesley. o „Software Release Methodology“ von Michael E. Bays, 1999 Prentice Hall PTR. Autor Mario Moreira schreibt Beiträge für Agile Journal und CM Journal , ist Buchautor und Experte für Agile Prozesse und Konfiguratio nsmanagement bei CA. Er arbeitet seit 1986 im Bereich SCM und seit 1998 im Feld der Agilen Prozesse. Mario hat Erfahrung mit vielen Technologien und Prozessen im SCM - Umfeld und hat SCM bei über 150 Anwendungen/Produkten umgesetzt, was auch den den Aufbau g lobaler SCM Infrastrukturen umfasst. Er ist zertifizierter ScrumMaster und hat im Bereich der Agilen Prozesse sowohl Scrum als auch XP implementiert. Er besitzt einen Abschluss als MA in Massenkom munikation mit Schwerpunkt Kommunikati onstechnologien. Mari o hat des W eiteren jahrelange Erfah rung mit Projektmanage ment, Softwarequalitätssicherung, Anforderungsmanagement, Prozessbeglei - tung und Teambildung. Mario ist Autor eines neuen Buches mit dem Titel „ Adapting Configuration Management for Agile Teams “ , w elches bei Wiley Publishing erschienen ist. Es bietet dem Leser eine Einführung in Agile Verfahren und Konfigurationsmanagement, Diskussion von Infrastruktur für Agile Prozesse unter Be rücksichtigung von Cloud - Infrastruktur, Hilfestellung bei der Anpassun g von CM - Praktiken für Agile Teams, Bewertung von Werkzeugen für Agile Prozesse, und Überlegungen zu Standards und Frame works in Agilen Umgebungen. Mario ist des weiteren Autor des SCM - Buches mit dem Titel „ Software Configuration Management Implementation Roadmap “ . Es enthält eine Schritt für Schritt Anleitung zur Implementierung von SCM auf den Ebenen der Organisation, des Produkts und des Projekts. Übersetzung Mit Unterstützung der elego Software Solutions GmbH wurde Mario Moreiras Artikel „ ABCs of a Br an ching and Merging Strategy“ von Neels J. Hofmeyr aus dem Englischen frei übersetzt. Das Unterneh men elego ist Anbieter von Softwareentwicklungsleistungen und Softwareprozessbe - ratung mit dem Schwer punkt auf Softwarekonfigurationsmanagement und verwand ten Disziplinen. Ins besondere be steht langjährige Erfahrung mit der Integration verschiedenster Werk zeuge zur Softwareprozessunter stützung. Zurzeit befassen sich mehrere Mitar beiter von elego aktiv mit der Wei terentwicklung von Apache Subversion.

7. © 2009 elego Software Solutions GmbH www.elego.de – Phone: +49 30 2345 8696 7 / 9 Erwägen Sie anschließend, wie die Komplexität sich mit der Zeit ändern könnte, z.B.: In den ersten sechs Monaten werden an “ project release 1 ” nur fünf Entwickler arbeiten, die nicht parallel und nur an einem Standort entwickeln. Nach einem Jahr wird “ project release 2 ” wahrscheinlich 15 Entwickler beschäftigen, die paral lel an release 2 , a n Korrekturen für release 1 und einem Prototypen für “ project release 3 ”, zu dem an zwei verschiedenen Standorten, arbeiten werden. Offensichtlich wird für das zweite Szenario eine viel umfangreichere Strategie vonnöten sein als für das erste. Deshalb ist es wichtig, Komplexität über Zeit zu erfassen. Komplexität erzeugt eine Notwen digkeit für branching , und Vorausdenken versichert, dass heute genutzte Strategien mit Leichtigkeit erweitert werden können um zukünftigen Anforderungen gerecht zu werden. Aufwa nd Je mehr parallel entwickelt wird, desto höher wird die Komplexität des branching . Mit zunehmender Komplexität wird es auch aufwändiger, Veränderungen zu verwalten. Das Projektmanagement sollte dies verstehen und planen. Höhere Komplexität und somit höhe rer Aufwand sind der Nachteil bei einem parallelen Entwicklungs modell. Während es zwar schnellere Veröffentlichung ermöglicht, erhöht Parallelität auch den Auf wand und den Koordinierungsbedarf in bestimmten Phasen der Projektentwicklung und bringt insbe sondere vermehrt merging und Testen auf den Projektplan. Bei jedem merge wird typischerweise er neutes Testen notwendig, um zuzusichern, dass der kombinierte Code gut funktioniert, insbesondere wenn logische Konflikte aufgelöst werden mussten. Ein weiterer Aspekt bei der Betrachtung des Aufwands ist die Projektmanagement - Strategie in der Ar beitsverteilung. Wenn gewisse komplette Teilaufgaben gewissen Gruppen zugewiesen werden, wird wahrscheinlich weniger merging und Testen stattfinden müssen. Ist das Proje ktmanagement aber wahllos im Verteilen der Aufgaben, kann das eine Menge merging und Testen, somit erhöhten Auf wand und sehr wahrscheinlich eine Hinauszögerung des Projektplans bedeuten. Dies trifft auch zu, wenn branching nicht verwendet wird. Benutzt ma n branching nicht, und ist es dann notwendig, an mehreren Stellen im Quelltext gleichzeitig zu arbeiten, kann selbst eine Zeile Quelltext eine Art der seriellen Entwicklung erzwingen, höchstwahr scheinlich eine Menge Testen verursachen und somit den Projek tplan beeinflussen. Dies kann auch dazu führen, dass viele Mitarbeiter außerhalb des CM Systems arbeiten, um sich von ihren Kollegen zu isolieren. Wenn es andererseits keine Notwendigkeit für parallele Entwicklung gibt, können zu viele branches verwirrend wirken und mehr Aufwand durch merging verursachen als erwünscht. Den „goldenen Mittelweg“ in dieser Entscheidung erreicht man durch die Analyse der Komplexität, und indem man dann mehrere verschiedene branching - Modelle identifiziert, die dieser Komplexität sstufe gerecht werden können. Anschließend kann das Ausmaß des Aufwands für jede Option erwägt wer den, um eine akzeptable Lösung zu finden. Instabilitätsrisiko Je komplexer der Entwicklungsprozess wird (siehe oben), desto höher wird auch das Risiko, die S tabi lität des Produkts durch ineffektive Verwaltung zu beeinträchtigen. An diesem Punkt verstehen Sie die Komplexität der Softwareentwicklung sowohl kurz - als auch langfristig, sowie den Aufwand, der mit verschiedenen branching - Modellen verbunden ist. Bet rachten Sie nun erneut die zuvor identifizierten branching - Modelle, und erwägen Sie, wieviel Instabilitätsrisiko sie eingehen wollen. Will man ein kleines Instabilitätsrisiko eingehen, sollte ein Integrations - branch verwendet werden, um die Stabilität des Projekt - branch s zu sichern. Während alle Änderungen in den Integrations - branch eingehen, gehen nur diejenigen Änderungen in den Projekt - branch ein, die

3. © 2009 elego Software Solutions GmbH www.elego.de – Phone: +49 30 2345 8696 3 / 9 tag Anhänger, Plakette, Schild; annähernd gleichbedeutend mit label milestone Meilenst ein; hier: ein Zwischenziel in der Softwareentwicklung build ein Bauvorgang; hier: das Kompilieren von Quellcode release Veröffentlichung major release Eine Veröffentlichung, bei der die bedeutendste Versionsnummer erhöht wird (zum Beispiel von 2.3 nach 3.0), also eine tiefgehende Neuerung des Produkts minor release Eine mit der vorigen Version kompatible Veröffentlichung workspace Arbeitsumgebung einer einzelnen Person; die eigene Kopie, an der entwickelt wird site Standort patch Flicken; hier: Korr ektur, kleine Erweiterung eines bestehenden Produkts CM configuration management ; Verwaltung und Lenkung der Erstellung und Änderung von Konfigurationen eines Produktes SCM software configuration management ; CM in Bezug auf Softwareentwicklung Build/Rel ease Engineer für die Veröffentlichung verantwortlicher Ingenieur Schlüsselkonzepte Was ist ein branch ? Ein branch ist eine isolierte Instanz einer existierenden Entwicklungslinie. Die zentrale Entwicklungslinie in einem branching - Modell wird oft trunk g enannt, oder auch Haupt - branch ( main branch ). Ein neuer branch kann entweder vom trunk oder von einem anderen branch ausgehen. Ein branch , von dem ein neuer branch abzweigt, wird der parent branch des neuen branch s genannt. Die Elemente eines branch s (ob p hysisch oder virtuell) sind ursprünglich identisch mit dem parent . Mit der Zeit jedoch werden sich die Elemente im branch weiterentwickeln. Durch Änderung, neues Erstel len oder Löschen der Elemente eines branch s wird er verschieden zu seinem parent . Ab bildung 1: Beispiel einer branch - Struktur

8. © 2009 elego Software Solutions GmbH www.elego.de – Phone: +49 30 2345 8696 8 / 9 sich in milestone builds und Tests bewiesen haben. Kleines Instabilitätsrisiko bedeutet auch, dass ver schiedene Standorte in verschiedenen branches arbeiten sollten, um diese voneinander zu isolieren. Allerdings bringt ein re duziertes Instabilitätsrisiko erhöhten Aufwand mit sich. Ein großes Instabilitätsrisiko bedeutet nicht direkt den vollständigen Verz icht auf branching , sondern lediglich, dass ein größeres Risiko in Kauf genommen wird, indem mehr Leute an weniger branches arbeiten. Beispielsweise kann ein großes Instabilitätsrisiko bedeuten, dass einige Standorte direkt in den Integrations - oder sogar in den Projekt - branch merg en dürfen, oder dass die workspaces der Ent wickler direkt vom Projekt - branch abstammen. Das Ende des Anfangs Die Frage ist also: Wollen Sie die Änderungen leiten, oder wollen Sie sich von den Änderungen leiten lassen? Sowohl eine übermäßige Miniaturisierung der Änderungen als auch eine zu starke Zusam menfassung können den benötigten Aufwand in der Entwicklung durch bran ching und merging und das Ausmaß nötiger Testläufe erheblich erhöhen. Der Schlüssel liegt im Gleichgewicht dies er Extre me. Zusammenfassend lauten die in diesem Artikel vorgestellten Schritte der Erarbeitung einer bran ching / merging - Strategie wie folgt: Verstehen Sie die Terminologie. Leihen Sie Begriffe von bestehendem Material oder entwi ckeln Sie eine eigene Ter minologie für Ihre Organisation, Ihre Anwendung oder Ihr Projekt. Verstehen Sie die Gründe für branching . Versichern Sie sich, dass diese sinnvoll sind und leicht Anderen erklärt werden kann. Ermitteln Sie die nötige Komplexität in der Produktentwicklung i m Sinne des branching und merging , um verschiedene hierzu passende Arten von branching zu identifizieren, und um zu bestimmen, wann merging stattfinden sollte. Erarbeiten Sie mehrere branching - Strategien. Schätzen Sie den benötigten Aufwand ab, den die ver schiedenen Strategien mit sich bringen. Entscheiden Sie sich, wieviel Instabilitätsrisiko Sie eingehen wollen, d.h. wie viel Instabilität Sie in den verschiedenen branches zulassen wollen. Bereiten Sie ein branching - Modell ähnlich der zweiten Abbildung vor , sodass die beteiligten Personen die branching / merging - Strategie visualisieren können und verstehen, an wel cher Stelle sie arbeiten. Gehen Sie mit ihnen ein Beispiel eines vollständigen Szenarios durch. Mit dieser Information kann ein branching - Modell mi t den benötigten Arten von branches und ihrer Konstellation entwickelt werden. Die Projektteams können die branch - Struktur und die vorgesehenen merge - Vorgänge sowie damit verbundenes Testen verstehen. Eine langfristige branching - Strategie kann Ihnen dabei helfen, Änderungen jetzt und in Zukunft zu verwalten.

2. © 2009 elego Software Solutions GmbH www.elego.de – Phone: +49 30 2345 8696 2 / 9 Das ABC des Branching und Merging von Mario Moreira Branching ist sowohl einfach als auch komplex – und für viele bleibt es ein Buch mit sieben S iegeln. Die ser Artikel benennt die Gründe für branching , erläutert dessen Konzepte und beschreibt verschie dene branching/merging - Strategien, um dem Leser eine solide Basis in diesem Themenbereich zu ver mitteln. Erarbeitet man eine branching/merging - Stra tegie und ein zugehöriges Modell, so ist es wichtig dabei das Projektmanagement mit einzubeziehen, da die Wahl einer Strategie den Entwicklungspro zess di rekt beeinflusst. Das Management sollte Teil des Entscheidungs - prozesses für eine branching - Stra tegi e sein, Vor - und Nachteile des branching verstehen und sich über den praktischen Aufwand im Klaren sein, den branching sowie dessen Fehlen mit sich bringen. Somit wird sichergestellt, dass die Erwartungen an das Projekt von Anfang an klar sind. Auch die be nutzte CM Software spielt eine Schlüsselrolle beim branching und merging . Manche CM Tools sind in dieser Disziplin schlicht besser als andere. Entsprechend ist ein CM Tool auszu wählen, das für die erarbeitete Entwicklungsstrategie geeignet ist. Glossar I n diesem Text werden häufig technische Begriffe wie branching , merging , trunk u.s.w. genutzt, die als Anglizismen im Deutschen Fachjargon direkt angewendet werden. Diese Wörter werden im Text des halb nicht übersetzt – stattdessen bietet das folgende Gloss ar Einsicht in die ursprüngliche Bedeutung der Englischen Wörter: Englisch Deutsch branch Ast oder Zweig eines Baumes branches Mehrzahl des Wortes branch (Um im Deutschen den Genitiv des Wortes branch von der Mehrzahl branches zu unterscheiden, verzicht et dieser Text auf das übliche 'e': viele branches , Elemente eines branch s.) to branch einen neuen Zweig in einer Baumstruktur anlegen branching “das Verzweigen”, in einer verzweigten Struktur verwalten to merge verschmelzen merging die Inhalte zweier verschiedener Punkte aus einer Baumstruktur kombinieren trunk Baumstamm main branch Haupt - branch , gleichbedeutend mit trunk development Entwicklung; hier: Softwareentwicklung baseline Basislinie; hier: ein bestimmter Zustand der Entwicklung parent Elt ernteil; hier: der direkte Abstammungsursprung parent branch Der branch , von dem der betrachtete branch ausgeht/abstammt. label Etikett, Beschriftung, Kennzeichnung

4. © 2009 elego Software Solutions GmbH www.elego.de – Phone: +49 30 2345 8696 4 / 9 Die Wörter branch (Zweig) und trunk (Stamm) werden verwendet, da eine visuelle Darstellung des branching Modells der Struktur eines Baumes ähnelt (siehe Abbildung 1). Jeder branch sollte einen eindeutigen Namen h aben, z.B. 'Branch A.1', um ihn von anderen branches zu unterscheiden. Ein kompletter branch Pfad sollte die Namen des trunk , aller parent branches und den eindeutigen Namen des branch s selbst enthalten, z.B. '/Trunk/Branch A/Branch A.1'. So wird der branc h nicht nur eindeutig identifiziert, sondern es wird auch seine vollständige Abstammung bis zum trunk deutlich. Diese Information wird später hilfreich beim Verständnis der Beziehungen zwischen branches , besonders wenn Elemente eines branch s mit einem ande ren branch verschmolzen werden sollen ( merging ). Was ist ein merge ? Ein merge ist ein Vorgang, der ein Element von einem branch mit einem gleich namigen Element eines anderen branch s kombiniert. Dabei wird das Endprodukt des merge als eine einfache Änderun g des Elementes auf einem der beiden branches gespeichert. Ein merge ist in der Regel nur sinnvoll, wenn die branches der zu verschmelzenden Elemente einen gemeinsamen Vor fahren haben. Ein Beispiel: foo.c ist ein Element des branch s 'Branch A.1' und ist a uf diesem branch geändert worden. Die gleiche Datei foo.c existiert auch als Element von 'Branch A', und ist ebenfalls geändert worden. Da beide Versionen sich auf branches mit gleichem Vorfahren befinden (in diesem Fall ist 'Branch A' der parent branch vo n 'Branch A.1'), kann hier ein merge stattfinden. Hier könnte der merge anschliessend als Änderung auf 'Branch A' eingehen. Was ist ein label ? Ein label bezeichnet bestimmte Versionen der Elemente innerhalb eines branch s. Der Begriff branch hat generell ei ne dynamische Bedeutung, so dass sich Elemente innerhalb eines branch s auch ändern können. Ein label dagegen bietet eine statische Identifikation des Zustands einer baseline zu einem bestimmten Zeitpunkt. Typischerweise werden labels nach jedem noch so kle inen erreichten milestone in der Entwicklung der Elemente eines branch s angelegt. Solche milestones sind z.B. ein erfolgreich abgeschlossener Integrations - build , ein neues Testpaket oder ein zur Produktion vorgesehenes release - Paket. Gründe für Branching Wann macht branching Sinn? Der Hauptgrund für branching ist die Notwendigkeit gleichzeitiger oder paralleler Entwicklung. Parallele Entwicklung heißt, dass zwei oder mehr isolierte Entwicklungslinien für verschiedene Zwecke von der gleichen baseline ausgeh end unterhalten werden. Wird branching verwendet, kann man einen release branch anlegen, um eine stabile release eines Projekts von der Hauptentwicklungslinie zu isolieren, welche typischerweise für die laufende Weiter entwicklung steht. Derart wird eine s tabile release nicht von neuen, evtl. qualitativ minderwertigen Ent wicklungen korrumpiert. Dies ist die einfachste Form von branching . Es gibt aber auch komplexere Gründe für branching. Einige Gründe für parallele Entwicklung auf der Projekt - Ebene sind: A rbeiten an zwei oder mehr Projektveröffentlichungen (zum Beispiel eine major und eine minor release , eine Spezialanfertigung für einen Kunden, Testen von Prototypen, Übersetzung auf eine andere Plattform, u.s.w.). Gleichzeitiges Arbeiten an einer neuen rel ease und an Korrekturen für eine ältere release . Einige Gründe für parallele Entwicklung innerhalb eines Projektes sind: Zusammenarbeit an verschiedenen Standorten (standortspezifischer branch , site specific branch ). Zusammenarbeit mehrerer Kollegen an ein em Standort (gemeinsam genutzter branch , shared branch ).

5. © 2009 elego Software Solutions GmbH www.elego.de – Phone: +49 30 2345 8696 5 / 9 Parallele Arbeiten innerhalb des eigenen workspace s (benutzerspezifischer, persönlicher branch ). Es können beliebig viele branches existieren. Allerdings sollte, bevor branches angewandt werden, ein e branching/merging - Strategie erarbeitet worden sein, um sicherzustel len, dass branches über haupt benötigt sind und dass die verwendete branching - Struktur für das Pro jekt Sinn macht. Zu viele branches können das Nachvollziehen der Entwicklung komplizier en, und zu we nig branches können im Entwicklungsprozess hinderlich sein. Viele Projektteams folgen der seriellen Entwicklungsstrategie und entwickeln direkt im trunk (oder Haupt - branch ). So gerät man allerdings leicht in Situationen, wo eine Abart der par allelen Entwicklung auf dem trunk stattfindet, was schnell zu Problemen führen kann. Es ist wichtig, im Voraus die Not wendigkeit für branching zu erkennen und eine Strategie hierfür vorzubereiten. Umgekehrt treffen vie le Projektmanager die Entscheidung z ur parallelen Entwicklungsstrategie, sind aber nicht ausreichend über die damit verbundene Komplexität und den Aufwand informiert. Es ist die Aufgabe des SCM , sich dieser Dinge bewusst zu sein, um die entsprechenden Gründe für oder gegen branching zu verst e hen. Branch - Typen Wie bereits erwähnt, beginnt die branch - Struktur mit dem trunk oder main branch . Darüberhinaus gibt es viele branch - Typen, die verschiedenen Anforderungen gerecht werden. Solche sind zum Beispiel: Pojekt - branch ( project branch ) – bei e inem großen Projekt wird dieser branch verwendet, um stabile Quelltext - Teile zu kombinieren. Bei einem kleinen Projekt dient dieser branch als Inte grationspunkt für alle in der Entwicklung vorgenommenen Änderungen. Mit solch einem branch wird die Stabilit ät gesichert. Er wird typischerweise in Verbindung mit einem Integrati ons - branch verwendet und stammt direkt vom trunk ab . Integrations - branch ( integration branch ) – wird als aktive Entwicklungslinie verwendet, um ent wicklungsbedingte Änderungen zu integ rieren. Diese Entwicklungslinie kann, abhängig vom Ausmaß vorgenommener merges , instabil sein. Ein Integrations - branch stammt meist direkt von einem Projekt - branch ab. Gemeinsam genutzter branch ( shared branch ) – ähnlich einem Integrations - branch wird er v on einer Teilgruppe der Entwickler genutzt, um unbeständigere Entwicklungen zu integrieren, wie z.B. das gründliche Testen von Prototypen, ohne andere Entwickler in ihrer Arbeit zu stören. Ein shared branch kann z.B. von einem Integrations - branch abstammen . Standortspezifischer branch ( site branch ) – ähnlich einem shared branch wird er verwendet, wenn verschiedene Standorte bei der Entwicklung beteiligt sind. Ein site branch isoliert die Ar beit verschiedener Standorte, erlaubt aber das Einbringen der Ergeb nisse in den Integrations - oder den Projekt - branch . Ein site branch stammt meist von einem Integrations - oder Projekt - branch ab. Privater branch ( private branch ) – dient der Isolation der durch einzelne Entwickler vorgenom menen Änderungen voneinander. Die ser stammt ab von einem der oben genannten branch - Typen. Einige Private branches können beispielsweise von einem shared branch stammen, während andere Private branches von einem Integrations - branch stammen. Korrektur - oder Erweiterungs - branch ( bugfix or pa tch branch ) – wird verwendet, um Fehlerkor rekturen oder kleine Erweiterungen ( bugfixes oder patches ) einer bestehenden release hinzu zufügen. Alle Änderungen auf diesem branch - Typ sollten durch einen merge sowohl 'einwärts' in den trunk (z.B. für die Prod uktion) als auch 'auswärts' in alle

Views

  • 36 Total Views
  • 23 Website Views
  • 13 Embedded Views

Actions

  • 0 Social Shares
  • 0 Likes
  • 0 Dislikes
  • 0 Comments

Share count

  • 0 Facebook
  • 0 Twitter
  • 0 LinkedIn
  • 0 Google+