it-swarm-eu.dev

Verzweigen oder nicht verzweigen?

Bis vor kurzem war mein Entwicklungsworkflow wie folgt:

  1. Holen Sie sich die Funktion vom Product Owner
  2. Erstellen Sie eine Verzweigung (wenn die Funktion länger als 1 Tag ist)
  3. Implementieren Sie es in einem Zweig
  4. Änderungen vom Hauptzweig zu meinem Zweig zusammenführen (um Konflikte beim Rückwärtszusammenführen zu reduzieren)
  5. Füge meinen Zweig wieder zum Hauptzweig zusammen

Manchmal gab es Probleme beim Zusammenführen, aber im Allgemeinen hat es mir gefallen.

Aber in letzter Zeit sehe ich immer mehr Anhänger der Idee, keine Zweige zu erstellen, da es schwieriger ist, kontinuierliche Integration, kontinuierliche Bereitstellung usw. zu üben. Und es klingt besonders lustig von Leuten mit verteiltem VCS-Hintergrund, die so viel über großartige Zusammenführungsimplementierungen von gesprochen haben Git, Mercurial usw.

Die Frage ist also, ob wir heutzutage Zweige verwenden sollen.

86
SiberianGuy

Wenn Sie nicht alle aus demselben Arbeitsbaum heraus arbeiten, verwenden Sie are Zweige, unabhängig davon, ob Sie sie so nennen oder nicht. Jedes Mal, wenn ein Entwickler in seinen Arbeitsbaum eincheckt, erstellt er einen separaten lokalen Entwicklungszweig und führt jedes Mal, wenn er eincheckt, eine Zusammenführung durch. Für die meisten Teams ist die Frage nicht wenn Sie verwenden Zweige, die Fragen sind wie viele und zu welchem ​​Zweck ?

Die einzige Möglichkeit, eine wirklich "kontinuierliche" Integration durchzuführen, besteht darin, dass jeder aus demselben Arbeitsbaum herausarbeitet. Auf diese Weise wissen Sie sofort, ob sich Ihre Änderungen nachteilig auf die anderer auswirken. Das ist natürlich unhaltbar. Sie benötigen ein gewisses Maß an Isolation in einer Verzweigung, um etwas zu erreichen, auch wenn diese "Verzweigung" nur Ihr lokales Arbeitsverzeichnis ist. Was benötigt wird, ist ein ausgewogenes Verhältnis von Integration und Isolation.

Nach meiner Erfahrung wird durch die Verwendung von mehr Zweigen verbessert der Integrationsgrad, da die Integration mit genau den Personen durchgeführt wird, die durchgeführt werden müssen, und alle anderen können nicht verwandte Probleme bei Bedarf leichter isolieren .

Zum Beispiel habe ich den letzten Tag damit verbracht, drei kürzlich eingeführte integrationsbezogene Fehler in unserem Build aufzuspüren, die meine "echte" Arbeit blockierten. Nachdem ich meine Sorgfalt darauf verwendet habe, diese Fehler den Personen zu melden, die sie beheben müssen, soll ich jetzt nur noch warten, bis sie fertig sind, um meine Arbeit fortzusetzen? Natürlich nicht. Ich habe einen temporären lokalen Zweig erstellt, der diese Änderungen zurücksetzt, damit ich eine stabile Basislinie habe, gegen die ich arbeiten kann, während ich weiterhin die neuesten Änderungen vom Upstream erhalte.

Ohne die Möglichkeit, zu diesem Zweck einen neuen Zweig zu erstellen, würde ich auf eine von drei Optionen reduziert: entweder die Änderungen im zentralen Repo rückgängig machen, die Patches, die sie zurücksetzen, manuell in meinem Arbeitsbaum pflegen und versuchen, sie nicht versehentlich einzuchecken oder kehren Sie zu einer Version zurück, bevor diese Fehler eingeführt wurden. Die erste Option wird wahrscheinlich eine andere Abhängigkeit aufheben. Die zweite Option ist viel Arbeit, daher wählen die meisten Leute die dritte Option, die Sie im Wesentlichen daran hindert, mehr Integrationsarbeit zu leisten, bis die zuvor gefundenen Fehler behoben sind.

In meinem Beispiel wurde eine private lokale Zweigstelle verwendet, aber das gleiche Prinzip gilt für gemeinsam genutzte Zweigstellen. Wenn ich meinen Zweig teile, können möglicherweise 5 andere Personen ihre Hauptaufgaben fortsetzen, anstatt redundante Integrationsarbeiten durchzuführen, sodass insgesamt nützlichere Integrationsarbeiten durchgeführt werden. Das Problem bei der Verzweigung und kontinuierlichen Integration ist nicht, wie viele Zweige Sie haben, sondern wie oft Sie sie zusammenführen.

64
Karl Bielefeldt

die Frage ist, sollten wir heutzutage Zweige verwenden?

Vor ungefähr einem halben Jahr wurde ich beauftragt, eine Studie durchzuführen, um diese Frage zu beantworten. Hier ist die Zusammenfassung, basierend auf den untersuchten Referenzen (unten aufgeführt)

  • Es gibt keine allgemein vereinbarte "beste" Verzweigungsstrategie für ein Projekt
    • die meisten Ressourcen scheinen zuzustimmen, dass die Wahl der Produktivstrategie von den jeweiligen Projektspezifikationen abhängt
    • randnotiz. Basierend auf dem oben Gesagten sieht es so aus, als müssten Änderungen an der Projektverzweigungsstrategie getestet, gemessen und mit anderen getesteten Optionen verglichen werden
  • die weit verbreitete Meinung ist, dass das Zusammenführen mit Subversion viele Anstrengungen erfordert. Alle, die SVN und Git verglichen haben, stellen fest, dass das Zusammenführen mit Git wesentlich einfacher ist
  • ein wichtiger Faktor scheint zu sein, ob Produktionsfreigaben aus Stamm oder Filialen stammen. Teams, die Prod Releases aus dem Trunk durchführen (was anscheinend nicht sehr beliebt ist), dürfen grundsätzlich keine instabile Trunk Strategie verwenden. Teams, die Produktfreigaben aus Zweigstellen durchführen, haben mehr Verzweigungsoptionen zur Auswahl.
  • beliebte Strategien scheinen zu sein stabiler Stamm, instabiler Stamm und Entwicklungszweig (Integration)

verweise

  • http://msdn.Microsoft.com/en-us/library/aa730834%28v=vs.80%29.aspx

    ... Die Entscheidung für die beste Verzweigungsstrategie ist ein Balanceakt. Sie müssen Produktivitätsgewinne gegen ein erhöhtes Risiko abwägen. Eine Möglichkeit, eine ausgewählte Strategie zu validieren, besteht darin, ein Änderungsszenario zu betrachten. Wenn Sie sich beispielsweise dazu entschließen, Zweige an der Systemarchitektur auszurichten (z. B. stellt ein Zweig eine Systemkomponente dar) und erhebliche Änderungen an der Architektur erwarten, müssen Sie möglicherweise Ihre Zweige und die zugehörigen Prozesse und Richtlinien bei jeder Änderung neu strukturieren. Die Wahl einer unzureichenden Verzweigungsstrategie kann zu Prozesskosten und langen Integrations- und Release-Zyklen führen, die sich für das gesamte Team als frustrierend erweisen ...
  • http://www.cmcrossroads.com/bradapp/acme/branching/

    ... Häufige, inkrementelle Integration ist einer der Wegweiser für den Erfolg, und ihre Abwesenheit ist oft ein Merkmal des Scheiterns. Gegenwärtige Projektmanagementmethoden neigen dazu, strenge Wasserfallmodelle zu vermeiden und die spiralförmigen Modelle der iterativen/inkrementellen Entwicklung und der evolutionären Bereitstellung zu berücksichtigen. Inkrementelle Integrationsstrategien wie Früh und häufig zusammenführen und seine Varianten sind eine Form des Risikomanagements, mit dem versucht wird, Risiken früher im Lebenszyklus auszuspülen, wenn mehr Zeit zur Verfügung steht, um darauf zu reagieren. Die Regelmäßigkeit des Rhythmus zwischen Integrationen wird von [Booch], [McCarthy] und [McConnell] als führender Indikator für die Projektgesundheit angesehen (wie ein "Puls" oder ein "Herzschlag").

    Eine frühzeitige und häufige Integration führt nicht nur dazu, dass das Risiko früher und in kleineren "Stücken" ausgearbeitet wird, sondern kommuniziert auch Änderungen zwischen Teamkollegen ...
  • http://www.codinghorror.com/blog/2007/10/software-branching-and-parallel-universes.html

    ... In den meisten Versionsverwaltungssystemen können Sie Hunderte von Zweigen ohne Leistungsprobleme erstellen. Es ist der mentale Aufwand, all die Zweige im Auge zu behalten, über die Sie sich wirklich Sorgen machen müssen ... Verzweigungen sind ein komplexes Tier. Es gibt Dutzende von Verzweigungsmöglichkeiten, und niemand kann Ihnen wirklich sagen, ob Sie es richtig oder falsch machen ...
  • http://www.lostechies.com/blogs/derickbailey/archive/2010/02/24/branching-strategies-when-to-branch-and-merge.aspx

    ... Es gibt viele Aspekte eines Systems, die beim Verzweigen Ihres Codes berücksichtigt werden müssen ... Am Ende besteht das Ziel darin, eine Sandbox für den Kontext bereitzustellen, in dem Code geschrieben wird. Das Verständnis der verfügbaren Optionen, wenn jede Option für die jeweilige Situation am besten geeignet ist und die Kosten dieser Optionen hilft Ihnen bei der Entscheidung, wie und wann verzweigt werden soll ...
  • http://www.snuffybear.com/ucm_branch.htm
    Beachten Sie angesichts der anderen hier aufgeführten Referenzen die Behauptung des Autors, dass "Dieser Artikel beschreibt drei wichtige Verzweigungsmodelle, die in Software Engineering-Projekten verwendet werden" nicht gerechtfertigt erscheint. Die verwendete Terminologie ist nicht weit verbreitet ( [~ # ~] efix [~ # ~], Model-1,2,3 etc).

  • http://svn.haxx.se/users/archive-2007-10/att-0101/SCMBranchingModels-talkback.pdf
    Die Referenz bietet ein interessantes Beispiel für Schwierigkeiten bei der Kommunikation von Verzweigungsstrategien.

  • http://simpleprogrammer.com/2010/06/04/simple-branching-strategy-part-1-back-to-basics/
    ...Halte es einfach. Direkt am Kofferraum zu arbeiten ist meiner Meinung nach bei weitem der beste Ansatz.

    Es klingt fast wie Häresie, wenn ich es tatsächlich auf meinen Bildschirm tippe, aber wenn Sie es einen Moment lang mit mir aushalten, werde ich Ihnen nicht nur zeigen, warum ich denke, dass dies für einen agilen Prozess wesentlich ist, sondern auch ich Ich werde Ihnen zeigen, wie es funktioniert ...

    ... Wenn ich meine Argumentation auf ein solides Argument stützen müsste, wäre dies der Wert einer kontinuierlichen Integration. Ich habe in der Vergangenheit über Wert von CI und Best Practices gebloggt. Ich bin ein ziemlich großer Verfechter von CI ...

    ... Sie müssen sich hier wirklich eine Frage stellen: "Ist der gesamte Aufwand, den Sie durch die Durchführung Ihrer komplizierten Verzweigungs- und Zusammenführungsstrategie verursachen, ein realer Wert, der gegenüber einer einfacheren Strategie nicht existiert?" ...

    ... Eine Strategie, die ich in der Vergangenheit effektiv angewendet und im Laufe der Zeit entwickelt habe. Ich werde es hier kurz zusammenfassen.

  • http://www.codelathe.com/blog/index.php/2009/07/02/a-svn-branching-strategy-that-works/
    ... Denken Sie schließlich daran, dass es keine ideale Verzweigungs- und Zusammenführungsstrategie gibt. Es hängt ziemlich stark von Ihrer einzigartigen Entwicklungsumgebung ab ...

  • http://blog.perforce.com/blog/?cat=62
    ... Das schlimmste Szenario ist, dass Sie ein "semantisches Zusammenführungsproblem" einführen, bei dem das Ergebnis einer automatisierten Zusammenführung falsch ist, aber OK kompiliert und sich an Tests vorbei schleicht und möglicherweise sogar lange genug überlebt, um Kunde zu werden -sichtbarer Fehler. Eek!

    Wenn Sie die Verletzung beleidigen, weil sie länger der Erkennung entgehen können, sind semantische Zusammenführungsprobleme später schwerer zu beheben, da die Änderung für den Entwickler, der die Änderung vorgenommen hat, nicht mehr aktuell ist. (Es ist normalerweise am besten, Änderungen kurz nach ihrer Durchführung zusammenzuführen, idealerweise von dem Entwickler, der die Änderung vorgenommen hat, wenn dies praktikabel ist.) ...

  • https://stackoverflow.com/questions/34975/branching-strategies
    Community-Mitglieder teilen unterschiedliche Erfahrungen in verschiedenen Projekten mit verschiedenen Verzweigungsstrategien. Kein vereinbarter Konsens über "am besten" oder "am schlechtesten".

  • http://www.stickyminds.com/s.asp?F=S16454_COL_2
    Im Wesentlichen eine kurze Zusammenfassung der in http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf präsentierten Inhalte

    • http://www.stickyminds.com/s.asp?F=S16511_COL_2
      ... Es gibt drei gängige Ansätze, um zu entscheiden, wann und wie verzweigt werden soll:
      • Erstellen Sie den Release-Zweig, wenn Sie "Feature abgeschlossen" haben, und planen Sie, Last-Minute-Probleme in dieser Codezeile zu beheben. In diesem Fall handelt es sich bei dem Release-Zweig tatsächlich um eine "Release-Prep-Codezeile", wie in Software Configuration Management Patterns beschrieben, da Sie davon ausgehen, dass noch viel zu tun ist.
      • Ändern Sie Ihren Arbeitsstil, um endgültige Integrationsarbeiten zu vermeiden, die außerhalb der aktiven Entwicklungslinie liegen.
      • Verzweigen Sie für die neue Arbeit, indem Sie einen Aufgabenzweig erstellen und diese Arbeit nach Abschluss der Version in der aktiven Entwicklungszeile zusammenführen.
        ... Ein Grund für die Verzweigung besteht darin, Code am Ende einer Version zu isolieren, damit er sich stabilisieren kann. Die Isolierung durch Verzweigung maskiert häufig ein Qualitätsproblem, das sich in den zusätzlichen Kosten für die Aufrechterhaltung paralleler Streams äußert, bevor ein Produkt veröffentlicht wird. Verzweigen ist einfach. Vielmehr ist es das Zusammenführen und der kognitive Aufwand, um zu verstehen, wie Änderungen zwischen Zweigen schwierig sind. Daher ist es wichtig, einen Prozess zu wählen, der die Kosten für das Verzweigen und Zusammenführen minimiert ...
  • http://nvie.com/posts/a-successful-git-branching-model/ Git-orientierte Strategie.
    ... Wir betrachten Origin/master als den Hauptzweig, in dem der Quellcode von HEAD immer eine Produktion widerspiegelt -ready state.

    Wir betrachten Origin/Develop als den Hauptzweig, in dem der Quellcode von HEAD immer einen Status mit den zuletzt gelieferten Entwicklungsänderungen für widerspiegelt Die nächste Version. Einige würden dies als "Integrationszweig" bezeichnen. Hier werden alle automatischen nächtlichen Builds erstellt aus ....

  • http://svnbook.red-bean.com/de/1.5/svn.branchmerge.html
    ... Projektrichtlinien variieren stark in Bezug darauf, wann es angemessen ist, einen Feature-Zweig zu erstellen. Einige Projekte verwenden überhaupt keine Feature-Zweige: Commits zu /trunk sind für alle kostenlos. Der Vorteil dieses Systems besteht darin, dass es einfach ist - niemand muss etwas über das Verzweigen oder Zusammenführen lernen. Der Nachteil ist, dass der Amtsleitungscode oft instabil oder unbrauchbar ist. Andere Projekte verwenden Verzweigungen bis zum Äußersten: Keine Änderung wird je direkt an den Trunk übergeben. Selbst die trivialsten Änderungen werden an einem kurzlebigen Zweig vorgenommen, sorgfältig überprüft und mit dem Stamm zusammengeführt. Dann wird der Zweig gelöscht. Dieses System garantiert jederzeit einen außergewöhnlich stabilen und nutzbaren Trunk, jedoch auf Kosten von enorm Prozessaufwand.

    Die meisten Projekte verfolgen einen Mid-of-the-Road-Ansatz. Sie bestehen häufig darauf, dass /trunk Regressionstests jederzeit kompilieren und bestehen. Ein Feature-Zweig ist nur erforderlich, wenn für eine Änderung eine große Anzahl destabilisierender Commits erforderlich ist. Eine gute Faustregel ist, diese Frage zu stellen: Wenn der Entwickler tagelang isoliert arbeitete und dann die große Änderung auf einmal festlegte (so dass /trunk niemals destabilisiert wurden), wäre dies der Fall Eine zu große Änderung, um sie zu überprüfen? Wenn die Antwort auf diese Frage "Ja" lautet, sollte die Änderung in einem Feature-Zweig entwickelt werden. Da der Entwickler inkrementelle Änderungen an der Niederlassung festlegt, können diese leicht von Kollegen überprüft werden.

    Schließlich gibt es die Frage, wie ein Feature-Zweig im Verlauf der Arbeit am besten mit dem Trunk synchronisiert werden kann. Wie bereits erwähnt, besteht ein großes Risiko, wochen- oder monatelang an einer Niederlassung zu arbeiten. Stammveränderungen können weiterhin auftreten, bis zu einem Punkt, an dem sich die beiden Entwicklungslinien so stark unterscheiden, dass es zu einem Albtraum werden kann, wenn versucht wird, den Zweig wieder mit dem Stamm zu verbinden.

    Diese Situation lässt sich am besten vermeiden, indem Stammwechsel regelmäßig mit dem Zweig zusammengeführt werden. Erstellen Sie eine Richtlinie: Führen Sie einmal pro Woche die Trunk-Änderungen der letzten Woche in der Filiale zusammen ...

  • http://thedesignspace.net/MT2archives/000680.html
    ... Dieser Abschnitt des Eclipse CVS-Tutorials basiert auf Paul Glezens Artikel auf der Eclipse-Website: Verzweigen mit Eclipse und CVS und wird mit seiner Erlaubnis gemäß den Bestimmungen des EPL-Lizenz. Die Änderungen, die ich an seiner Version vornehme, bestehen hauptsächlich darin, sie mit Schritt-für-Schritt-Bildern und Erklärungen zu erweitern und sie in meine eigenen Anfänger-Tutorials zu integrieren, um sie Anfängern und Designern zugänglicher zu machen. Erfahrene Entwickler werden es wahrscheinlich vorziehen, mit Pauls Version zu arbeiten ...

  • http://learnsoftwareprocesses.com/2007/12/29/common-branching-strategies/
    ... Hier sind einige der gängigen Verzweigungsmodelle:

    1. Branch-by-Release-Modell: Eine der häufigsten Verzweigungsstrategien besteht darin, Zweige an Produktversionen auszurichten. Eine Niederlassung enthält alle Softwareentwicklungsressourcen für eine einzelne Version. Gelegentlich müssen Updates von einer Version zur anderen zusammengeführt werden, werden jedoch normalerweise nie zusammengeführt. Zweigniederlassungen werden eingestellt, wenn eine Freigabe eingestellt wird.
    2. Filiale pro Promotion: Ein weiterer sehr verbreiteter Ansatz besteht darin, Filialen an den Promotion-Levels für Software-Assets auszurichten. Eine bestimmte Entwicklungsversion wird in einen Testzweig verzweigt, in dem alle Integrations- und Systemtests durchgeführt werden. Wenn Sie die Tests abgeschlossen haben, werden die Softwareentwicklungsressourcen in den Produktionszweig verzweigt und schließlich bereitgestellt.
    3. Zweig pro Aufgabe: Um überlappende Aufgaben (oder Aktivitäten) und Produktivitätsverluste zu vermeiden, können Sie diese in einem separaten Zweig isolieren. Beachten Sie, dass dies kurzfristige Zweige sind, die zusammengeführt werden sollten, sobald die Aufgabe abgeschlossen ist. Andernfalls kann der erforderliche Zusammenführungsaufwand die Produktivitätsvorteile der erstmaligen Erstellung übersteigen.
    4. Zweig pro Komponente: Sie können jeden Zweig an der Systemarchitektur ausrichten. Bei dieser Strategie verzweigen Sie einzelne Komponenten (oder Subsysteme). Anschließend entscheidet jedes Team, das eine Komponente entwickelt, wann der Code wieder in die Entwicklungslinie eingefügt wird, die als Integrationszweig dient. Diese Strategie kann gut funktionieren, wenn die Systemarchitektur vorhanden ist und die einzelnen Komponenten genau definierte Schnittstellen haben. Die Tatsache, dass Sie Komponenten in Zweigen entwickeln, ermöglicht eine genauere Kontrolle über Softwareentwicklungsressourcen.
    5. Branch per Technology: Eine weitere Verzweigungsstrategie, die auf die Systemarchitektur abgestimmt ist. In diesem Fall sind die Niederlassungen auf Technologieplattformen ausgerichtet. Allgemeiner Code wird in einem separaten Zweig verwaltet. Aufgrund der Einzigartigkeit der in den Filialen verwalteten Softwareentwicklungsressourcen werden sie wahrscheinlich nie zusammengeführt ...
  • http://msdn.Microsoft.com/en-us/library/bb668955.aspx
    ... Eine Zusammenfassung der Verzweigungs- und Zusammenführungsrichtlinien finden Sie in den Richtlinien zum Verzweigen und Zusammenführen in "Richtlinien zur Quellcodeverwaltung" in diesem Handbuch. ... Beachten Sie beim Verzweigen Folgendes:

    • Verzweigen Sie nicht, es sei denn, Ihr Entwicklungsteam muss gleichzeitig an denselben Dateien arbeiten. Wenn Sie sich nicht sicher sind, können Sie einen Build kennzeichnen und zu einem späteren Zeitpunkt einen Zweig aus diesem Build erstellen. Das Zusammenführen von Zweigen kann zeitaufwändig und komplex sein, insbesondere wenn zwischen ihnen erhebliche Änderungen bestehen.
    • Strukturieren Sie Ihre Verzweigungsbäume so, dass Sie nur entlang der Hierarchie (auf und ab des Verzweigungsbaums) und nicht über die Hierarchie hinweg zusammenführen müssen. Für die Verzweigung über die Hierarchie muss eine unbegründete Zusammenführung verwendet werden, die eine manuellere Konfliktlösung erfordert.
    • Die Verzweigungshierarchie basiert auf dem übergeordneten und dem untergeordneten Verzweigungszweig, die sich möglicherweise von der physischen Struktur des Quellcodes auf der Festplatte unterscheiden. Beachten Sie bei der Planung Ihrer Zusammenführungen eher die logische Zweigstruktur als die physische Struktur auf der Festplatte.
    • Verzweigen Sie nicht zu tief. Da die Ausführung jeder Zusammenführung und Lösung von Konflikten einige Zeit in Anspruch nimmt, kann eine tiefe Verzweigungsstruktur dazu führen, dass Änderungen in einem untergeordneten Zweig sehr lange dauern, bis sie in den Hauptzweig übertragen werden. Dies kann sich negativ auf die Projektpläne auswirken und die Zeit für die Behebung von Fehlern verlängern.
    • Verzweigen Sie auf hoher Ebene und enthalten Sie Konfigurations- und Quelldateien.
    • Entwickeln Sie Ihre Verzweigungsstruktur im Laufe der Zeit.
    • Für das Zusammenführen müssen ein oder mehrere Entwickler die Zusammenführung ausführen und Konflikte lösen. Die zusammengeführte Quelle muss gründlich getestet werden, da es nicht ungewöhnlich ist, schlechte Zusammenführungsentscheidungen zu treffen, die den Build destabilisieren können.
    • Das Zusammenführen über die Zweighierarchie hinweg ist besonders schwierig und erfordert, dass Sie viele Konflikte manuell behandeln, die andernfalls automatisch behandelt werden könnten.
      Die Entscheidung, ob eine Zweigstelle erstellt werden soll, kann dahingehend reduziert werden, ob die Kosten für das Zusammenführen von Konflikten in Echtzeit höher sind als die Gemeinkosten für das Zusammenführen von Konflikten zwischen Zweigstellen ...
  • http://kashfarooq.wordpress.com/2009/11/23/Bazaar-branching-strategy-with-a-Subversion-trunk/

    • http://kashfarooq.wordpress.com/2010/12/16/Bazaar-branching-strategy-with-a-Subversion-trunk-revised/
    • http://kashfarooq.wordpress.com/2009/11/02/using-Bazaar-feature-branches-with-a-Subversion-trunk/
    • http://kashfarooq.wordpress.com/2009/09/08/Bazaar-or-git-moving-away-from-Subversion/
      ... Kommt Ihnen eine dieser Subversion-Beschwerden bekannt vor?
      • Sie werden nach dem Zufallsprinzip angewiesen, dass "Sie das Update ausführen müssen". Sie führen dann ein Update durch - das dauert ewig. Und schließlich sehen Sie, dass keine Änderungen heruntergeladen werden mussten.
      • Sie werden nach dem Zufallsprinzip angewiesen, dass "Sie eine Bereinigung ausführen müssen".
      • Sie haben große Zusammenführungsprobleme. Beispielsweise verwenden Sie ReSharper, um eine Klasse umzubenennen, und einige andere haben diese Klasse in der Zwischenzeit aktualisiert. Sie sehen dann den gefürchteten Baumkonfliktfehler (Schauder). Oder noch schlimmer, Sie benennen einen ganzen Namespace und Ordner um (Double Shudder). Jetzt bist du wirklich in einer Welt voller Schmerzen.
      • Ihre Zusammenführungen erfolgen in der Regel immer mehr manuell. Sie müssen häufig WinMerge verwenden, da Subversion keine Ahnung hat.
      • Sie warten oft darauf, dass Tortoise aktualisiert/auf Änderungen/irgendetwas überprüft wird.

        Ich habe ein Subversion-Repository auf meinem USB-Stick. Ich bekomme Baumkonflikte und füge Probleme damit zusammen, und ich bin der einzige Benutzer!

        Das Hauptproblem ist das Zusammenführen ...
    • "Subversion saugt" kommt mir bekannt vor. Zeit zu hören Joel und Linus ?
  • http://social.msdn.Microsoft.com/Forums/en/tfsversioncontrol/thread/f127676c-8f05-410c-9a30-0eb43a26a9fa
    Diskussion der Best Practice für die Release Isolation Branch-Strategie bei sich entwickelnden Systemen.

  • http://branchingguidance.codeplex.com/
    "Microsoft Team Foundation Server-Verzweigungsanleitung" - großes und detailliertes Dokument mit Empfehlungen, die auf verschiedene Projekte zugeschnitten sind: HTML-Version hier . Beweist, dass Microsoft nicht an einen einheitlichen Ansatz für Verzweigungsstrategien glaubt.

  • https://stackoverflow.com/questions/597707/best-branching-strategy-when-doing-continuous-integration
    Was ist die beste Verzweigungsstrategie, wenn Sie eine kontinuierliche Integration durchführen möchten? ... Die Antwort hängt von der Größe Ihres Teams und der Qualität Ihrer Quellcodeverwaltung sowie von der Fähigkeit ab, komplexe Änderungssätze korrekt zusammenzuführen ...

  • http://codicesoftware.blogspot.com/2010/03/branching-strategies.html
    ... CVS und SVN haben die gesamte Verzweigungs-/Zusammenführungsstrategie entmutigt, da sie dazu überhaupt nicht in der Lage waren ... ... Einfache Regel: Erstellen Sie für jede neue Funktion oder jeden neuen Bugfix einen Task-Zweig implementieren ... Es kann für SVN/CVS-Benutzer wie ein Overkill klingen, aber Sie wissen, dass Sie mit jedem modernen SCM in einer Sekunde Zweige erstellen können, sodass kein wirklicher Overhead entsteht.

    Wichtiger Hinweis: Wenn Sie es sich genau ansehen, werden Sie feststellen, dass ich über die Verwendung von Aufgabenzweigen als Rich-Man-Änderungslisten spreche ...

  • http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.cc_proj.doc/c_bntr_plnbrstrat.htm
    ... Die Verzweigungspolitik wird von den Entwicklungszielen des Projekts beeinflusst und bietet einen Mechanismus zur Steuerung der Entwicklung der Codebasis. Es gibt so viele Variationen von Verzweigungsrichtlinien wie Organisationen, die die Versionskontrolle von Rational ClearCase verwenden. Es gibt aber auch Ähnlichkeiten, die die gemeinsame Einhaltung von Best Practices widerspiegeln ...

  • http://blogs.open.collab.net/svn/2007/11/branching-strat.html
    ... Das Subversion-Modell (oder genauer gesagt das allgemeine Open-Source-Modell) wird im instabilen Trunk-Modell gezeigt ...

  • http://en.wikipedia.org/wiki/Trunk_%28software%29
    Im Bereich der Softwareentwicklung bezieht sich trunk auf das unbenannte branch (version) eines Dateibaums unter Revisionskontrolle =. Der Kofferraum soll normalerweise die Basis eines Projekts sein, auf dem die Entwicklung voranschreitet. Wenn Entwickler ausschließlich am Trunk arbeiten, enthält dieser immer die neueste Version des Projekts, ist jedoch möglicherweise auch die instabilste Version. Ein anderer Ansatz besteht darin, einen Zweig vom Trunk abzutrennen, Änderungen in diesem Zweig zu implementieren und die Änderungen wieder in den Trunk zusammenzuführen, wenn sich der Zweig als stabil und funktionsfähig erwiesen hat. Je nach Entwicklungsmodus und Commit -Richtlinie enthält der Trunk möglicherweise die stabilste oder die am wenigsten stabile oder eine dazwischen liegende Version.

    Häufig finden die Hauptentwicklerarbeiten im Trunk statt und stabile Versionen werden verzweigt, und gelegentliche Fehlerkorrekturen werden von den Zweigen zum Trunk zusammengeführt. Wenn die Entwicklung zukünftiger Versionen in Nicht-Trunk-Zweigen erfolgt, erfolgt dies normalerweise für Projekte, die sich nicht häufig ändern oder bei denen die Entwicklung einer Änderung voraussichtlich lange dauern wird, bis sie in den Trunk integriert werden kann. .

  • http://www.mcqueeney.com/roller/page/tom/20060919
    ... Dies sind Notizen aus einem Webinar zu Best Practices für Subversion , das am 30. August 2006 von CollabNet durchgeführt wurde. ... Zwei Organisationsstrategien: instabiler Kofferraum vs. stabiler Kofferraum ... ... bevorzugen Sie einen instabilen Kofferraum, wenn möglich ...

  • https://stackoverflow.com/questions/153812/Subversion-ist-trunk-really-the-best-place-for-the-main-development
    In SVN ist Trunk der empfohlene Ort für die Hauptentwicklung, und ich verwende diese Konvention für alle meine Projekte. Dies bedeutet jedoch, dass der Trunk manchmal instabil oder sogar kaputt ist. Wäre es nicht besser, die "wilde Entwicklung" auf einem Zweig wie/branch/dev durchzuführen und nur dann zum Trunk zu verschmelzen, wenn der Build angemessen ist solide?

    • ... Im Kofferraum soll die Weiterentwicklung stattfinden. Sie sollten wirklich kein Problem mit "defektem" Code haben, wenn jeder seine Änderungen testet, bevor er sie festschreibt. Eine gute Faustregel ist, ein Update durchzuführen (den neuesten Code aus den Repos abzurufen), nachdem Sie Ihre Änderungen codiert haben. Dann bauen und einige Unit-Tests durchführen. Wenn alles baut und funktioniert, sollten Sie gut darin sein, es einzuchecken ...
    • ... Nein, Kofferraum ist nicht der beste Ort. In unserer Organisation verfolgen wir immer diesen Ansatz: Trunk enthält Release-Code und wird daher immer kompiliert. Mit jeder Veröffentlichung/jedem Meilenstein eröffnen wir eine neue Niederlassung. Wenn ein Entwickler ein Element besitzt, erstellt er einen neuen Zweig für diesen Release-Zweig und führt ihn erst nach dem Testen zu einem Release-Zweig zusammen. Der Release-Zweig wird nach dem Systemtest mit dem Trunk zusammengeführt ...
  • http://blog.yclian.com/2009/03/working-on-branches-and-stable-trunk.html
    ... Ich habe früher am Trunk gearbeitet, weil ich bei allen Projekten, an denen ich gearbeitet habe, entweder der einzige Entwickler war oder das Team dafür gesorgt hat, dass jeder Code-Check-in die lokalen Tests bestanden hat. Andernfalls haben wir (noch) Zweige für Fehlerkorrekturen, großen Code für neue Funktionen usw. erstellt.

    Vor ungefähr 2 Monaten hatte ich eine kurze Git-Session mit Kamal und er teilte mir die Idee von Geschichte/Zweig mit. Und als mein Team mit mehr Entwicklern zu wachsen begann, habe ich das Bedürfnis, mehr Verzweigungen zu fördern, und jetzt ist dies eine Regel geworden. Für ein Projekt mit automatisierten Tests, die mit CI definiert wurden, ist ein stabiler Kofferraum garantiert, und diese Vorgehensweise kann sehr gut dazu passen.

    Wir verwenden kein Git, sondern Subversion, weil wir so angefangen haben und uns jetzt (meistens) immer noch damit wohl fühlen ...

  • http://www.ericsink.com/scm/scm_branches.html
    Dies ist Teil eines Online-Buches mit dem Titel Source Control HOWTO , einem Best Practices-Handbuch zur Quellcodeverwaltung, Versionskontrolle und Konfigurationsverwaltung ...

    ... Erics bevorzugte Verzweigungspraxis ... Behalte einen "im Grunde instabilen" Kofferraum. Machen Sie Ihre aktive Entwicklung im Rumpf, dessen Stabilität zunimmt, wenn Sie sich der Freisetzung nähern. Erstellen Sie nach dem Versand eine Wartungsniederlassung und halten Sie diese immer sehr stabil ...

    ... Im nächstes Kapitel werde ich mich mit dem Thema des Zusammenführens von Zweigen befassen ...

  • http://marc.info/?l=forrest-dev&m=112504297928196&w=2
    Mail des Threads starten, in dem Verzweigungsstrategien für das Projekt Apache Forrest besprochen werden

    • beachten Sie, dass das Projekt derzeit anscheinend ein instabiles Trunk-Modell mit Release-Zweigen verwendet:
    • "Entwicklungsarbeiten werden am Stamm von SVN durchgeführt ... Es gibt" Release-Zweige "von SVN, z. B. forrest_07_branch." ( Projektrichtlinien )
    • "Erstellen der Release Candidate-Pakete ... 17. Erstellen Sie einen Wartungszweig in SVN ..." ( Release )
  • O'Reilly CVS-Verzweigungsdokumente:
    http://commons.oreilly.com/wiki/index.php/Essential_CVS/Using_CVS/Tagging_and_Branching#Basically_stable

    • ... Die grundsätzlich stabile Verzweigungsphilosophie besagt, dass der Trunk Projektdaten enthalten sollte, die immer kurz vor der Veröffentlichung stehen ... ... Mildere Variationen dieser Philosophie ermöglichen es, alles, was Entwickler-Unit-Tests besteht, in das zu integrieren Kofferraum. Solch ein entspannter Ansatz erfordert, dass ein Release-Kandidat vor der Veröffentlichung abgezweigt und einer vollständigen QS-Analyse unterzogen wird ...
    • ... Die grundsätzlich instabile Philosophie besagt, dass der Trunk unabhängig von seiner Stabilität den neuesten Code enthalten sollte und dass Release-Kandidaten für die Qualitätssicherung abgezweigt werden sollten.


      ... Mildere Variationen ermöglichen auch die Verzweigung von experimentellem Code, Refactoring und anderem Sonderfallcode. Das Zusammenführen eines Zweigs zurück in den Stamm erfolgt durch die Manager des Zweigs. ...
      • Hinweis: Die obige Ressource wurde in keiner der von mir durchgeführten Suchvorgänge angezeigt (CVS-bezogene Richtlinien sind nicht mehr beliebt?).
  • Best Practices in SCM (Perforce-Artikel) at
    http://www.perforce.com/perforce/papers/bestpractices.html
    ... sechs allgemeine Bereiche der SCM-Bereitstellung und einige grobkörnige Best Practices in jedem dieser Bereiche. In den folgenden Kapiteln werden die einzelnen Elemente erläutert ...
    Arbeitsbereiche, Codelines, Verzweigungen, Änderungsausbreitung, Builds, Prozesse ...

81
gnat

Wenn mehrere Teams gleichzeitig an verschiedenen Funktionen arbeiten, können Sie die Verzweigung nicht auslassen. Sie sollten (teilweise implementierten) Code mit Teammitgliedern teilen, um zu verhindern, dass andere Teams Ihre nicht abgeschlossenen Funktionen erhalten.

Zweige sind der einfachste Weg, dies zu erreichen.

Obwohl es gut ist, den Lebenszyklus von Zweigen zu verkürzen und zu vermeiden, dass in zwei Zweigen gleichzeitig an demselben Modul gearbeitet wird, treten dann keine Konflikte\Zusammenführungsprobleme auf.

7
Shaddix

Aber in letzter Zeit sehe ich immer mehr Anhänger der Idee, keine Zweige zu gründen, da es schwieriger ist, kontinuierliche Integration, kontinuierliche Bereitstellung usw. zu praktizieren.

Nun, macht es schwieriger, kontinuierliche Integration, kontinuierliche Bereitstellung usw. zu üben für Sie konkret?

Wenn nicht, sehe ich keinen Grund, Ihre Arbeitsweise zu ändern.

Natürlich ist es empfehlenswert zu verfolgen, was los ist und wie sich die aktuellen Best Practices entwickeln. Aber ich denke nicht, dass wir unsere Prozesse/Tools/so weiter aufgeben müssen, nur weil X (und/oder Y und/oder Z) gesagt haben, dass sie keine Modeerscheinung mehr sind :-)

5
Péter Török

Was für eine interessante Reihe von Antworten. In mehr als 20 Jahren habe ich noch nie in einem Unternehmen gearbeitet, das die Verzweigung mehr als nur trivial genutzt hat (im Allgemeinen nur für Verzweigungsversionen).

Die meisten Orte, an denen ich gearbeitet habe, basieren auf relativ schnellen Eincheckvorgängen und einer schnellen Erkennung/Lösung von Kollisionen. Die agile Methodik lehrt, dass Sie Probleme schneller lösen können, wenn Sie sie bemerken, während beide Parteien aktiv über diesen Code nachdenken.

Andererseits habe ich git nicht viel benutzt und vielleicht hat die Aufnahme des git-Tags diese Antworten beeinflusst - ich verstehe, dass Verzweigen/Zusammenführen mit git eine Selbstverständlichkeit ist, weil es so einfach ist.

4
Bill K

Ja, Sie sollten Zweige verwenden, um (zumindest mittleren) Entwicklungsaufwand zu isolieren. Siehe " Wann sollten Sie verzweigen? ".

Das Problem besteht eher darin, Schnellvorlaufzusammenführungen zu verwenden (die einen Zweigverlauf in einem anderen enthalten), vorausgesetzt, Sie quetschen zuerst alle "Zwischenprüfpunkt-Commits" (was im Fall eines Rollbacks oder git bisect Ein Problem sein kann). .
Siehe " Git-Workflow verstehen ", um private Zweige (die nicht verschoben werden sollen) von öffentlichen Zweigen zu unterscheiden, die durch bereitgestellte ff-Zusammenführungen (Schnellvorlauf-Zusammenführungen) vervollständigt werden dass Sie die erforderliche Bereinigung innerhalb des Zweigs vornehmen, den Sie zusammenführen.
Siehe auch " Warum verwendet Git standardmäßig das Schnellvorlauf-Zusammenführen? ".

3
VonC

Wir haben das gerade (wieder) durchgemacht. Zuerst hatten wir die gesamte GIT/SVN-Debatte, die uns allgemein zu Verzweigungsstrategien führte.

Die größeren Unternehmen verwenden alle eine Trunk-basierte Strategie, bei der alle in derselben Niederlassung arbeiten und von dieser Niederlassung aus aufgebaut und kontinuierlich integriert werden. Das Vermeiden von Konflikten erfolgt durch Codemodularisierung, Feature-Switching und clevere Tools. Das klingt schwierig .. weil es ist. Aber wenn Sie diese Debatte führen, dann deshalb, weil Sie den Fantasien der Menschen über die Verzweigung zum Opfer gefallen sind. Einige behaupten, sie verwenden SCM-Tool hier einfügen mit einem vollständig Sarbanes-Oxley-konformen Promotion-Verzweigungsmechanismus, und alles ist brillant. Sie lügen entweder, täuschen sich selbst oder arbeiten nicht auf dem gleichen Systemmaßstab wie Sie.

Das Verzweigen und Zusammenführen ist schwierig. Vor allem, wenn Sie ein Unternehmen haben, das regelmäßig seine Meinung ändert und Rollbacks usw. verlangt.

Dieser Satz kann Ihr Leben retten: Was im SCM enthalten ist, ist nicht dasselbe wie das, was in Ihren gebauten Artefakten enthalten ist!

Wenn Sie Probleme mit der Verzweigung haben, liegt dies daran, dass Sie Ihr SCM missbrauchen. Wir alle machen das schon seit Jahren. Sie haben ein System eingerichtet, in dem das SCM verwendet wird, um zu bestimmen, was in Ihren endgültigen Build einfließt.

Das ist nicht die Aufgabe des SCM. Der SCM ist ein verherrlichter Dateiserver. Die Aufgabe, zu bestimmen, welche Dateien von Ihrem SCM in Ihren Build aufgenommen werden, gehört zu Ihrem Build-Tool.

Modul A wird bearbeitet und geht in Ihre wöchentliche Veröffentlichung. Modul B ist Modul A, enthält jedoch Projekt X und wird im selben Zweig bearbeitet, jedoch nicht in Ihre Version integriert. Irgendwann in der Zukunft möchten Sie Projekt X freigeben. Sie weisen Ihr Build-Tool also an, das Einfügen von Modul A zu beenden und das Einfügen von Modul B zu starten.

Es wird viel Weinen und Handdrücken geben. Was für ein Problem und allgemeines Heulen. Dies ist das Gefühlsniveau, das etwas so Einfaches wie ein Datei-Repository umgibt, egal wie clever es auch sein mag.

Aber da ist deine Antwort.

2
Richard

Sie sollten unbedingt Zweige verwenden. Das hat eine Reihe von Stärken.

  • Sie können Ihre Arbeit unterwegs einchecken, wenn Sie Bedenken haben, aufgrund eines HD-Fehlers, eines Laptop-Verlusts usw. Arbeit zu verlieren, und das Haupt-CI dadurch nicht beschädigt wird.
  • Sie können weiterhin CI ausführen. Richten Sie einfach Ihr eigenes lokales CI ein, um Ihren Zweig zu überwachen.
  • Wenn die Funktion plötzlich angehalten wird (das passiert nie), können Sie sie einfach parken.

Zu hart ist niemals eine Entschuldigung. Es erfordert immer mehr Mühe, es richtig zu machen.

2
Bill Leeper

Wenn zwei Teams in ihrem eigenen Zweig arbeiten, werden die Änderungen des anderen Teams nicht angezeigt, selbst wenn beide den Zweig master integrieren. Das würde bedeuten, dass ihre Entwicklungszweige auseinander driften und wenn eines der Teams mit master fusionieren würde, muss das andere Team viele Änderungen neu begründen.

Selbst wenn Sie Zweige für Features haben, würde ich Sie dringend bitten, "Backports" aller Refactorings zum Hauptzweig zu erstellen und den Zweig nur für neue Features beizubehalten.

  • Refactorings von Backports

Ich denke, manchmal ist es einfacher, Feature-Schalter zu verwenden, um neue, nicht getestete Features zu deaktivieren, die noch nicht in Produktion gehen sollten. Auf diese Weise werden alle anderen Teams die Änderungen sehen und es muss keine Urknall-Fusion stattfinden.

  • Verwenden Sie Funktionsschalter
2
flob

Das Hauptproblem bei der Verzweigung ist die Schwierigkeit, nach Abschluss der Entwicklung wieder in die Hauptverzweigung zurückzukehren. Das Zusammenführen kann ein manueller und fehleranfälliger Prozess sein, daher sollte es die meiste Zeit vermieden werden.

Einige bemerkenswerte Ausnahmen, bei denen ich die Verzweigung bevorzuge, sind massives Refactoring, riesige Features, deren Entwicklung länger als ein Sprint dauert, oder störende Features, die die Entwicklung anderer Features während des größten Teils dieses Sprints unterbrechen würden.

1
maple_shaft

Ich empfehle diese Art von Verzweigungsschema:

release - Test - Entwicklung

Verzweigen Sie dann von der Entwicklung nach Entwickler und/oder Feature.

Entwickler haben jeweils einen Zweig, mit dem sie spielen und von dem sie routinemäßig in den Entwicklungszweig übergehen können - idealerweise jeden Tag (vorausgesetzt, er wird kompiliert).

Diese Art von Schema funktioniert sehr gut mit vielen Entwicklern und mehreren Projekten auf derselben Codebasis.

1
Paul Nathan

Der Prozess in meiner Organisation verwendet in großem Umfang Zweige nd (ein Prozess, der ein bisschen aussieht) kontinuierliche Integration.

Auf hoher Ebene sorgen sich Entwickler nicht zu sehr um das Zusammenführen mit der Hauptlinie, sondern verpflichten sich lediglich zur Niederlassung. Ein (halb-) automatisierter Prozess überprüft, welche Funktionen in die Hauptlinie aufgenommen werden sollen, führt diese Zweige zusammen und erstellt das Produkt. Der Prozess funktioniert, weil wir diesen Prozess des Zusammenführens tatsächlich aus dem Issue-Tracker integrieren, sodass das Build-Tool weiß, welche Zweige zusammengeführt werden sollen.

Wir tun verwenden Zweige, aber nicht auf der granularen Ebene des Merkmals. Wir verwenden Zweige für jeden Sprint. Verzweigen ist im Wesentlichen keine schlechte Sache, IMO, da es das Konzept von SOC in der Feature- oder Sprint-Ebene simuliert. Sie können leicht erkennen und verwalten, welcher Zweig zu welchem ​​Feature oder Sprint gehört.

IMHO, dann lautet die Antwort JA . Wir sollten immer noch die Verzweigung verwenden.

0
Saeed Neamati