Verzweigen oder nicht verzweigen?

Bis vor kurzem war mein Entwicklungsworkflow wie folgt:

1. Holen Sie sich die Funktion vom Product Owner
2. Zweig erstellen (wenn die Funktion länger als 1 Tag ist)
3. Implementieren Sie es in einer Filiale
4. Änderungen vom Hauptzweig in meinen Zweig zusammenführen (um Konflikte beim Zusammenführen in Rückwärtsrichtung zu verringern)
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 machen, 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 Filialen verwenden sollten.

Es sei denn , Sie arbeiten alle aus dem gleichen Arbeits Baum sind, Sie sind mit Zweigen, ob man 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 lautet die Frage nicht, ob Sie Zweige verwenden, sondern wie viele und zu welchem ​​Zweck ?

Die einzige Möglichkeit, eine wirklich "kontinuierliche" Integration zu erreichen, 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. Notwendig ist ein ausgewogenes Verhältnis von Integration und Isolation.

Meiner Erfahrung nach verbessert die Verwendung von mehr Zweigen den Integrationsgrad, da die Integration genau mit den Personen durchgeführt wird, für die sie erforderlich ist, und alle anderen Probleme bei Bedarf leichter eingrenzen können.

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 diese Fehler mit der gebotenen Sorgfalt den Leuten gemeldet habe, die sie beheben müssen, soll ich jetzt nur noch warten, bis sie fertig sind, um meine Arbeit fortzusetzen? Natürlich nicht. Ich habe eine temporäre lokale Verzweigung erstellt, die diese Änderungen zurücksetzt, damit ich eine stabile Basislinie habe, gegen die ich vorgehen kann, während ich immer noch die neuesten Änderungen vom Upstream erhalte.

Ohne die Möglichkeit, einen neuen Zweig für diesen Zweck zu erstellen, würde ich mich auf eine von drei Möglichkeiten beschränken: entweder die Änderungen im zentralen Repository rückgängig machen, die Patches, die sie zurücksetzen, manuell in meinem Arbeitsbaum verwalten und versuchen, sie nicht versehentlich einzuchecken , oder kehren Sie zu einer Version zurück, bevor diese Bugs eingeführt wurden. Die erste Option wird wahrscheinlich eine andere Abhängigkeit aufheben. Die zweite Option ist sehr arbeitsintensiv, daher entscheiden sich die meisten für die dritte Option, die im Wesentlichen verhindert, dass Sie mehr Integrationsarbeit leisten, bis die zuvor gefundenen Fehler behoben sind.

In meinem Beispiel wurde eine private lokale Zweigstelle verwendet, aber dasselbe Prinzip gilt für gemeinsam genutzte Zweigstellen. Wenn ich meine Niederlassung teile, können möglicherweise 5 andere Personen ihre primären Aufgaben fortsetzen, anstatt redundante Integrationsarbeiten auszuführen, sodass insgesamt nützlichere Integrationsarbeiten ausgeführt werden. Das Problem bei der Verzweigung und kontinuierlichen Integration ist nicht, wie viele Zweige Sie haben, sondern wie oft Sie sie zusammenführen.

Die Frage ist, ob wir heutzutage Zweige verwenden sollen.

Nun, 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 Auswahl der Produktivstrategie von den jeweiligen Projektspezifikationen abhängt
  • Randnotiz. Auf der Grundlage des oben Gesagten scheint es notwendig zu sein, Änderungen an der Verzweigungsstrategie des Projekts zu testen, zu messen und mit anderen getesteten Optionen zu vergleichen
• Die weitverbreitete Meinung ist, dass der Zusammenschluss 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 von Stamm oder Zweig stammen. Teams, die Produktfreigaben vom Trunk durchführen (was anscheinend nicht sehr beliebt ist), ist es grundsätzlich untersagt, eine Strategie für instabile Trunks zu verwenden. Teams, die Produktfreigaben aus Filialen durchführen, haben mehr Verzweigungsoptionen zur Auswahl.
• beliebte Strategien scheinen stabiler Rumpf, instabiler Rumpf und Entwicklungs- (Integrations-) Zweig zu sein

Verweise

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

  ... Die Entscheidung für die beste Verzweigungsstrategie ist ein Spagat. Sie müssen Produktivitätsgewinne gegen ein erhöhtes Risiko abwägen. Eine Möglichkeit, eine gewählte Strategie zu validieren, besteht darin, ein Änderungsszenario zu betrachten. Wenn Sie sich beispielsweise dafür entscheiden, Zweige an der Systemarchitektur auszurichten (ein Zweig stellt beispielsweise eine Systemkomponente dar) und erhebliche architektonische Änderungen erwarten, müssen Sie möglicherweise Ihre Zweige und die zugehörigen Prozesse und Richtlinien bei jeder Änderung neu strukturieren. Die Auswahl einer unangemessenen Verzweigungsstrategie kann zu einem Prozess-Overhead und zu langen Integrations- und Release-Zyklen führen, die für das gesamte Team frustrierend sind ...

• 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 vermeiden strenge Wasserfallmodelle und berücksichtigen die spiralförmigen Modelle der iterativen / inkrementellen Entwicklung und der evolutionären Umsetzung. Inkrementelle Integrationsstrategien wie Merge Early and Often und seine Varianten sind eine Form des Risikomanagements, mit dem versucht wird, Risiken früher im Lebenszyklus auszuschließen, wenn mehr Zeit zum Reagieren bleibt. Die Regelmäßigkeit des Rhythmus zwischen den Integrationen wird von [Booch], [McCarthy] und [McConnell] als führender Indikator für die Gesundheit des Projekts angesehen (wie ein "Puls" oder ein "Herzschlag").  
   
  Eine frühe und häufige Integration kann nicht nur das Risiko früher und in kleineren "Brocken" ausloten, sondern auch Veränderungen zwischen Teamkollegen kommunizieren ...

• 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, um die Sie sich wirklich Sorgen machen müssen. Das Verzweigen ist ein komplexes Biest. Es gibt Dutzende von Möglichkeiten, sich zu verzweigen, 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 bei der Verzweigung 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. Wenn Sie die verfügbaren Optionen kennen, wissen Sie, wann sie für die jeweilige Situation am besten geeignet sind, und die Kosten für diese Optionen , um zu entscheiden, wie und wann Sie ...

• http://www.snuffybear.com/ucm_branch.htm
  Beachten Sie bei anderen hier aufgeführten Verweisen die Behauptung des Autors, dass "dieser Artikel drei wichtige Verzweigungsmodelle beschreibt, die in Software Engineering-Projekten verwendet werden" nicht gerechtfertigt erscheint. Die verwendete Terminologie ist nicht weit verbreitet ( EFIX , Model-1,2,3 usw.).

• http://svn.haxx.se/users/archive-2007-10/att-0101/SCMBranchingModels-talkback.pdf Die
  Referenz enthält 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/
  ... Halten Sie es einfach. Direkt vom Kofferraum aus zu arbeiten, ist meiner Meinung nach der mit Abstand beste Ansatz.  
   
  Es klingt fast wie eine Irreführung, wenn ich es auf meinem Bildschirm eintippe, aber wenn Sie einen Moment mit mir aushalten, zeige ich Ihnen nicht nur, warum ich denke, dass dies für einen agilen Prozess wesentlich ist, sondern ich zeige Ihnen auch, wie damit es funktioniert ...  
   
  ... Wenn ich meine Argumentation auf ein solides Argument stützen müsste, wäre es der Wert einer kontinuierlichen Integration. Ich habe in der Vergangenheit über den Wert von CI und Best Practices gebloggt. Ich bin ein ziemlich großer Befürworter von CI ...  
   
  ... Sie sich hier wirklich eine Frage haben zu fragen: „Ist die ganze Kopf Sie tun , um Ihre komplizierten Verzweigungen werden entstehen und Strategie in einem realen Wert , der sich verschmelzenden , die nicht über eine einfache Strategie existiert?“ ...  
   
  .. Eine Strategie, die ich in der Vergangenheit effektiv eingesetzt und im Laufe der Zeit entwickelt habe. Ich werde es hier kurz zusammenfassen.

  • Jeder arbeitet aus dem Kofferraum.
  • Verzweigen Sie, wenn Sie Code freigeben.
  • Verzweigen Sie eine Version, wenn Sie eine Fehlerbehebung für bereits veröffentlichten Code erstellen müssen.
  • Abzweig für Prototypen.
    ...
    • http://simpleprogrammer.com/2010/06/07/simple-branching-strategy-part-2-implementation/
      ... ziemlich detaillierte Anleitung ...

• 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ührungs" -Problem einführen, bei dem das Ergebnis einer automatischen Zusammenführung falsch ist, aber in Ordnung kompiliert wird und sich in die Vergangenheit schleicht Testen, möglicherweise sogar lange genug, um ein vom Kunden sichtbarer Fehler zu sein. Eek!  
   
  Die Verletzung wird zusätzlich beleidigt, da sie sich der Erkennung länger entziehen kann. Probleme mit semantischen Zusammenführungen sind später schwerer zu beheben, da die Änderung für den Entwickler, der die Änderung vorgenommen hat, nicht mehr aktuell ist. (Es ist in der Regel am besten, Änderungen kurz nach dem Durchführen zusammenzuführen, im Idealfall vom Entwickler, der die Änderung vorgenommen hat, sofern dies praktikabel ist.) ...

  • http://blog.perforce.com/blog/?p=1635
    Hinweis: Die empfohlene Richtlinie ähnelt dem in http://www.infoq.com/articles/agile-version-control#q11 und http definierten Entwicklungszweig : //msdn.microsoft.com/en-us/library/bb668955.aspx
  • Erklärung zum Promotion-Modell: http://www.perforce.com/perforce/papers/life.html

• https://stackoverflow.com/questions/34975/branching-strategies
  Community-Mitglieder teilen unterschiedliche Erfahrungen in verschiedenen Projekten mit unterschiedlichen Verzweigungsstrategien. Kein Konsens über "das Beste" oder "das Schlechteste".

  • http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf
    "klassisches" Lesen - erläuterte Terminologie wie Mainline Model , Codeline etc

• 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 enthaltenen Informationen

  • 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 die Release-Verzweigung, wenn Sie "Feature abgeschlossen" sind, und planen Sie, Last-Minute-Probleme in dieser Codezeile zu beheben. In diesem Fall handelt es sich bei dem Release-Zweig in Wirklichkeit um eine "Release-Prep-Code-Zeile", wie in Software Configuration Management Patterns beschrieben , da davon ausgegangen wird, dass noch viel zu tun ist.
    • Ändern Sie Ihren Arbeitsstil, um eine endgültige Integrationsarbeit zu vermeiden, die von der aktiven Entwicklungslinie abweicht.
    • Verzweigen Sie für die neue Arbeit, indem Sie einen Aufgabenzweig erstellen und diese Arbeit nach Abschluss der Freigabe in der aktiven Entwicklungslinie zusammenführen.
      ... Ein Grund für die Verzweigung besteht darin, Code am Ende einer Veröffentlichung zu isolieren, damit er sich stabilisieren kann. Isolation durch Verzweigung maskiert häufig ein Qualitätsproblem, das sich in den zusätzlichen Kosten für die Aufrechterhaltung paralleler Streams manifestiert, bevor ein Produkt freigegeben wird. Das Verzweigen ist einfach. Vielmehr ist es das Zusammenführen und der kognitive Aufwand zu verstehen, wie Änderungen zwischen Zweigen ablaufen, die 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 einen produktionsbereiten Zustand widerspiegelt .  
   
  Wir betrachten Origin / Develop als den Hauptzweig, in dem der Quellcode von HEAD immer einen Stand mit den neuesten Entwicklungsänderungen für die nächste Version widerspiegelt. Einige würden dies den "Integrationszweig" nennen. Hier werden alle automatischen nächtlichen Builds erstellt.

  • Etwas ähnlich der Strategie für Entwicklungszweige , wie in http://www.infoq.com/articles/agile-version-control#q11 und http://msdn.microsoft.com/en-us/library/bb668955.aspx definiert

• http://svnbook.red-bean.com/en/1.5/svn.branchmerge.html
  ... Die Projektrichtlinien variieren stark und betreffen genau den Zeitpunkt, an dem ein Feature-Zweig erstellt werden soll. Einige Projekte verwenden überhaupt keine Feature-Verzweigungen: Commits an / trunk sind für alle kostenlos. Der Vorteil dieses Systems ist, dass es einfach ist - niemand muss etwas über das Verzweigen oder Zusammenführen lernen. Der Nachteil ist, dass die Amtskennziffer oft instabil oder unbrauchbar ist. Andere Projekte nutzen Zweige in extremem Maße : Keine Änderung wird jemals direkt auf den Stamm übertragen. Selbst die geringfügigsten Änderungen werden auf einem kurzlebigen Zweig erstellt, sorgfältig überprüft und zum Stamm zusammengeführt. Dann wird der Zweig gelöscht. Dieses System garantiert zu jeder Zeit einen außergewöhnlich stabilen und nutzbaren Kofferraum, was jedoch enorme Kosten verursachtOverhead verarbeiten.  
   
  Bei den meisten Projekten handelt es sich um Mid-of-the-Road-Projekte. Sie bestehen im Allgemeinen darauf, dass / trunk jederzeit kompiliert und Regressionstests besteht. Ein Feature-Zweig ist nur erforderlich, wenn eine Änderung eine große Anzahl destabilisierender Commits erfordert. 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 nie destabilisiert wurde), wäre es eine zu große Änderung, um sie zu überprüfen? Wenn die Antwort auf diese Frage "Ja" lautet, sollte die Änderung für einen Feature-Zweig entwickelt werden. Wenn der Entwickler inkrementelle Änderungen an der Zweigstelle festlegt, können diese problemlos von Kollegen überprüft werden.  
   
  Schließlich stellt sich die Frage, wie ein Feature-Zweig bei fortschreitender Arbeit am besten mit dem Trunk synchronisiert werden kann. Wie wir bereits erwähnt haben, besteht ein großes Risiko, wochen- oder monatelang an einem Zweig zu arbeiten. Stammveränderungen können weiterhin eintreten, 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 zusammenzuführen.  
   
  Diese Situation lässt sich am besten vermeiden, indem Stammänderungen regelmäßig in der Zweigstelle zusammengeführt werden. Machen Sie eine Richtlinie: Führen Sie einmal pro Woche die Stammänderungen der letzten Woche in der Zweigstelle 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 unter den Bedingungen von verwendet die EPL-Lizenz. Die Änderungen, die ich an seiner Version vornehme, bestehen hauptsächlich darin, sie schrittweise mit Bildern und Erklärungen zu erweitern und sie in meine eigenen Tutorials für Anfänger zu integrieren, um sie Anfängern und Designern zugänglicher zu machen. Erfahrene Entwickler werden es wahrscheinlich vorziehen, mit Pauls Version zu arbeiten ...

  • http://www.eclipse.org/articles/article.php?file=Article-BranchingWithEclipseAndCVS/article1.html
  • http://www.eclipse.org/articles/article.php?file=Article-BranchingWithEclipseAndCVS/article2.html

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

  1. Branch-by-Release-Modell: Eine der gebräuchlichsten Verzweigungsstrategien besteht darin, die Zweige an den Produktfreigaben auszurichten. Eine Niederlassung hält alle Softwareentwicklungsressourcen für eine einzelne Version. Gelegentlich müssen Aktualisierungen von einer Version zu einer anderen zusammengeführt werden, in der Regel werden sie jedoch nie zusammengeführt. Zweige werden eingestellt, wenn eine Veröffentlichung eingestellt wird.  
  2. Filiale pro Promotion: Ein weiterer sehr verbreiteter Ansatz ist die Ausrichtung von Filialen an den Promotion-Levels für Software-Assets. Eine bestimmte Entwicklungsversion wird in einen Testzweig verzweigt, in dem alle Integrations- und Systemtests durchgeführt werden. Wenn Sie das Testen abgeschlossen haben, werden die Softwareentwicklungsressourcen in den Zweig Produktion verzweigt und schließlich bereitgestellt.  
  3. Zweigstelle pro Aufgabe: Um sich überschneidende Aufgaben (oder Aktivitäten) und Produktivitätsverluste zu vermeiden, können Sie diese in einer separaten Zweigstelle isolieren. Beachten Sie, dass es sich um kurzfristige Zweige handelt, die nach Abschluss der Aufgabe zusammengeführt werden sollten, da sonst der erforderliche Aufwand für das Zusammenführen möglicherweise die Produktivitätsvorteile bei der erstmaligen Erstellung übersteigt.  
  4. Zweig pro Komponente: Sie können jeden Zweig an der Systemarchitektur ausrichten. In dieser Strategie verzweigen Sie einzelne Komponenten (oder Subsysteme). Anschließend entscheidet jedes Team, das eine Komponente entwickelt, wann der Code wieder in der Entwicklungslinie zusammengeführt werden soll, die als Integrationszweig dient. Diese Strategie kann gut funktionieren, wenn die Systemarchitektur vorhanden ist und die einzelnen Komponenten gut definierte Schnittstellen haben. Die Tatsache, dass Sie Komponenten in Zweigen entwickeln, ermöglicht eine genauere Steuerung der Softwareentwicklungsressourcen.  
  5. Branch per Technology: Eine weitere Verzweigungsstrategie, die auf die Systemarchitektur abgestimmt ist. In diesem Fall sind die Filialen auf Technologieplattformen ausgerichtet. Allgemeiner Code wird in einem separaten Zweig verwaltet. Aufgrund der Einzigartigkeit der Softwareentwicklungsressourcen, die in den Filialen verwaltet werden, werden sie wahrscheinlich nie zusammengeführt ...

• http://msdn.microsoft.com/en-us/library/bb668955.aspx
  ... Eine Zusammenfassung der Richtlinien zum Verzweigen und Zusammenführen finden Sie in den Richtlinien zum Verzweigen und Zusammenführen unter "Richtlinien zur Quellcodeverwaltung" in diesem Handbuch. ... Beachten Sie beim Verzweigen Folgendes:

  • Verzweigen Sie nicht, es sei denn, Ihr Entwicklungsteam muss gleichzeitig an demselben Satz von 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 sich zwischen ihnen erhebliche Änderungen ergeben.
  • Strukturieren Sie Ihre Verzweigungsbäume so, dass Sie nur entlang der Hierarchie (auf und ab der Verzweigungsbaumstruktur) und nicht über die Hierarchie hinweg zusammenführen müssen. Das Verzweigen über die Hierarchie erfordert die Verwendung einer unbegründeten Zusammenführung, die eine manuellere Konfliktlösung erfordert.
  • Die Verzweigungshierarchie basiert auf dem übergeordneten Zweig und dem untergeordneten Zweig, die sich möglicherweise von der physischen Struktur des Quellcodes auf der Festplatte unterscheiden. Beachten Sie bei der Planung Ihrer Zusammenführungen die logische Zweigstruktur und nicht die physische Struktur auf der Festplatte.
  • Nicht zu tief verzweigen. Da die Ausführung aller Zusammenführungs- und Auflösungskonflikte einige Zeit in Anspruch nimmt, kann eine tiefgreifende Verzweigungsstruktur dazu führen, dass die Übertragung von Änderungen in einem untergeordneten Zweig sehr lange dauert. Dies kann sich negativ auf die Projektpläne auswirken und die Zeit zur Behebung von Fehlern erhöhen.
  • Verzweigen Sie auf hoher Ebene, und fügen Sie Konfigurations- und Quelldateien hinzu.
  • Entwickeln Sie Ihre Verzweigungsstruktur im Laufe der Zeit.
  • Beim 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 selten vorkommt, dass Zusammenführungsentscheidungen getroffen werden, die den Build destabilisieren können.
  • Das Zusammenführen über die Zweigstellenhierarchie hinweg ist besonders schwierig und erfordert, dass Sie viele Konflikte manuell behandeln, die andernfalls automatisch behandelt werden könnten.  
    Die Entscheidung, ob ein Zweig erstellt werden soll, lässt sich dahingehend reduzieren, dass 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 Zweigen ...

• 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/
    ... Kennen Sie eine dieser Beschwerden von Subversion?
    • Sie werden nach dem Zufallsprinzip angewiesen, dass "Sie das Update ausführen müssen". Anschließend führen Sie ein Update durch, dessen Fertigstellung Ewigkeiten in Anspruch nimmt. Und schließlich sehen Sie, dass keine Änderungen heruntergeladen werden mussten.
    • Sie werden nach dem Zufallsprinzip angewiesen, dass "Sie die Bereinigung ausführen müssen".
    • Sie haben große Zusammenführungsprobleme. Beispielsweise verwenden Sie ReSharper, um eine Klasse umzubenennen, und andere haben diese Klasse in der Zwischenzeit aktualisiert. Sie sehen dann den gefürchteten Baumkonfliktfehler (Schauder). Oder noch schlimmer: Sie benennen einen gesamten Namespace und Ordner um (Double Shudder). Jetzt bist du wirklich in einer Welt voller Schmerzen.
    • Ihre Zusammenführungen werden in der Regel immer manueller. Sie müssen WinMerge häufig verwenden, da Subversion keine Ahnung hat.
    • Sie warten oft darauf, dass Tortoise aktualisiert / auf Änderungen überprüft.  
       
      Ich habe ein Subversion-Repository auf meinem USB-Stick. Ich bekomme Baumkonflikte und verschmelze Probleme damit, und ich bin der einzige Benutzer!  
       
      Das Hauptproblem ist die Verschmelzung ...  
       
  • "subversion sucks" kommt mir bekannt vor. Zeit, Joel und Linus zuzuhören ?

• 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 Branching Guidance" - umfangreiches und detailliertes Dokument mit Empfehlungen für verschiedene Projekte: 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://www.zeroturnaround.com/blog/continuous-integration-and-feature-branches/ Detaillierte Analyse des Verzweigungsspiels mit kontinuierlicher Integration, basierend auf konkreten Erfahrungen mit Hudson / Jenkins - zusammen mit einigen nützlichen Referenzen
    . Meine größte Entdeckung war, dass bei CI zwar das häufige Festschreiben, Weiterleiten und Abrufen von Feedback im Vordergrund steht (dh der CI-Cluster gibt Ihnen Feedback, das Ihre Workstation Ihnen niemals in der gleichen Zeitspanne geben könnte), bei dem puristischen CI jedoch eine weitere Anforderung besteht - dass das Team an der gleichen Grundlinie arbeiten muss ...
    Verwendete Materialien
    • Best Practices für mehrere Zweige - in der Jenkins-Liste veröffentlichen
    • Ist es möglich, mehrere Zweige zu verwalten, in denen einige Jobs auf jedem ausgeführt werden sollen, ohne sie zu duplizieren ? Schreiben Sie sie in die Jenkins-Liste
    • Parallele Entwicklung mit Zweigen - auf Jenkins Liste setzen
    • Hudson-Job automatisch konfigurieren oder erstellen - stackoverflow.com
    • Kontinuierliche Integration in die Entwicklung mehrerer Niederlassungen - stackoverflow.com
    • Behandlung mehrerer Zweige in Continuous Integration - stackoverflow.com
    • Kontinuierliche Integration - Martin Fowler
    • Kontinuierliche Integration - Wikipedia

• 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 einen Task-Zweig für jede neue Funktion oder jeden neuen Bugfix, den Sie implementieren müssen. Für SVN / CVS-Benutzer kann dies wie ein Overkill klingen, aber Sie wissen, dass Sie mit jedem modernen SCM in Sekundenschnelle Zweige erstellen können, sodass kein wirklicher Overhead entsteht.  
   
  Wichtiger Hinweis: Wenn Sie genau hinschauen, werden Sie feststellen, dass ich die Verwendung von Task-Zweigen als Rich-Man-Änderungslisten meine ...

• http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.cc_proj.doc/c_bntr_plnbrstrat.htm
  ... Die Verzweigungsrichtlinie wird von der Entwicklung beeinflusst Ziele des Projekts und bietet einen Mechanismus zur Steuerung der Entwicklung der Codebasis. Es gibt so viele Variationen von Verzweigungsrichtlinien wie Organisationen, die die Rational ClearCase-Versionskontrolle verwenden. Es gibt jedoch auch Gemeinsamkeiten, die die Einhaltung bewährter Verfahren widerspiegeln ...

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

• http://en.wikipedia.org/wiki/Trunk_%28software%29
  Im Bereich der Software - Entwicklung, Stamm bezieht sich auf die unbenannte Zweig (Version) eines Dateibaum unter Revisionskontrolle . Der Kofferraum soll in der Regel die Basis eines Projekts sein, auf dem die Entwicklung voranschreitet. Wenn Entwickler ausschließlich am Trunk arbeiten, enthält er immer die neueste Version des Projekts, kann jedoch auch die instabilste Version sein. Ein anderer Ansatz besteht darin, einen Zweig vom Stamm abzuspalten, Änderungen in diesem Zweig zu implementieren und die Änderungen wieder in den Stamm zusammenzuführen, wenn sich der Zweig als stabil und funktionsfähig erwiesen hat. Abhängig von Entwicklungsmodus und Commitrichtlinie der trunk kann die stabilste oder die am wenigsten stabile oder etwas dazwischen liegende version enthalten.  
   
  Oft findet die Hauptarbeit der Entwickler im Trunk statt, und stabile Versionen werden verzweigt, und gelegentliche Fehlerbehebungen werden von den Zweigen zum Trunk zusammengeführt. Wenn die Entwicklung zukünftiger Versionen in Nicht-Trunk-Zweigen durchgeführt wird, wird dies normalerweise für Projekte durchgeführt, die sich nicht häufig ändern oder bei denen die Entwicklung einer Änderung voraussichtlich lange dauert, bis sie für die Integration in den Trunk bereit ist. .

• http://www.mcqueeney.com/roller/page/tom/20060919
  ... Dies sind Notizen aus einem Webinar über bewährte Methoden von Subversion , das am 30. August 2006 von CollabNet durchgeführt wurde. ... Zwei Organisationsstrategien: instabiler Kofferraum vs. stabiler Kofferraum ... ... nach Möglichkeit einen instabilen Kofferraum bevorzugen ...

• https://stackoverflow.com/questions/153812/subversion-is-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 ihn nur dann zum Trunk zusammenzuführen, wenn der Build vernünftig 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 es, ein Update durchzuführen (holen Sie sich den neuesten Code von den Repos), nachdem Sie Ihre Änderungen codiert haben. Dann bauen Sie und machen Sie einige Unit-Tests. Wenn alles funktioniert und funktioniert, sollten Sie es gut einchecken ...
  • ... Nein, Kofferraum ist nicht der beste Ort. In unserer Organisation verfolgen wir immer diesen Ansatz: Trunk enthält Versionscode und wird daher immer kompiliert. Mit jedem neuen Release / Meilenstein eröffnen wir eine neue Filiale. Wenn ein Entwickler ein Element besitzt, erstellt er einen neuen Zweig für diesen Freigabezweig und führt ihn erst nach dem Testen zu einem Freigabezweig zusammen. Freigabezweig wird nach Systemtest in Trunk zusammengeführt ...

• http://blog.yclian.com/2009/03/working-on-branches-and-stable-trunk.html
  ... Früher habe ich am Kofferraum gearbeitet, weil ich es bei allen Projekten, an denen ich gearbeitet habe, entweder war oder war Der einzige Entwickler oder das Team hat dafür gesorgt, dass jeder beim Code-Check-In die lokalen Tests bestanden hat. Ansonsten haben wir (noch) Zweige für Fehlerbehebungen, 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 Entwicklerteams zu wachsen begann, habe ich das Bedürfnis, mehr Verzweigungen zu fördern, und jetzt ist dies zur Regel geworden. Für ein Projekt mit automatisierten Tests, die mit CI-Setup definiert wurden, ist ein stabiler Stamm garantiert, und diese Praxis kann sehr gut dazu passen.  
   
  Wir verwenden kein git, sondern Subversion, weil wir so angefangen haben und immer noch damit vertraut sind (die meiste Zeit) ...

• http://www.ericsink.com/scm/scm_branches.html
  Dies ist Teil eines Online-Handbuchs mit dem Titel " Source Control HOWTO" , einem Handbuch mit bewährten Methoden zur Versionskontrolle, Versionskontrolle und Konfigurationsverwaltung ...  
   
  ... Eric's Preferred Branching Üben ... Halten Sie einen "im Grunde instabilen" Kofferraum. Tun Sie Ihre aktive Entwicklung im Kofferraum, dessen Stabilität sich erhöht, wenn Sie sich der Freigabe nähern. Erstellen Sie nach dem Versand einen Wartungszweig und halten Sie ihn immer sehr stabil ...  
   
  ... Im nächsten Kapitel werde ich mich mit dem Thema Zusammenführen von Zweigen befassen ...

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

  • Beachten Sie, dass das Projekt derzeit anscheinend ein instabiles Stammmodell mit Release-Zweigen verwendet:
  • "Die Entwicklungsarbeit wird am Stamm von SVN geleistet ... Es gibt" Veröffentlichungszweige "von SVN, z. B. forrest_07_branch." ( Projektrichtlinien )
  • "Erstellen der Release Candidate-Pakete ... 17. Erstellen Sie einen Wartungszweig in SVN ..." ( Freigeben )

• O'Reilly CVS-Verzweigungsdokumente:
  http://commons.oreilly.com/wiki/index.php/Essential_CVS/Using_CVS/Tagging_and_Branching#Basically_stable
  

  • ... Die im Grunde stabile Verzweigungsphilosophie besagt, dass der Trunk Projektdaten enthalten sollte, die immer kurz vor der Veröffentlichung stehen Kofferraum. Solch ein entspannter Ansatz erfordert, dass ein Release-Kandidat verzweigt und vor der Veröffentlichung einer vollständigen QS-Analyse unterzogen wird ...
  • ... Die im Grunde 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.
     
     
    ... Höhere Abweichungen ermöglichen auch die Verzweigung für experimentellen Code, Refactoring und anderen Sonderfallcode. Das Zusammenführen einer Niederlassung zurück in den Stamm wird von den Managern der Niederlassung vorgenommen. ...
    • Hinweis: Die oben genannte Ressource wurde in keiner der von mir durchgeführten Suchen angezeigt. (CVS-bezogene Richtlinien sind nicht mehr beliebt?)

• Best Practices in Bezug auf SCM (siehe Artikel) unter
  http://www.perforce.com/perforce/papers/bestpractices.html
  ... sechs allgemeine Bereiche der SCM-Bereitstellung sowie einige grobkörnige Best Practices in jedem dieser Bereiche. In den folgenden Kapiteln werden die einzelnen
  Elemente erläutert. Arbeitsbereiche, Codelines, Verzweigungen, Änderungsweitergabe, Builds, Prozesse ...

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

Zweige sind der einfachste Weg, dies zu erreichen.

Es ist zwar gut, den Lebenszyklus von Zweigen zu verkürzen und zu vermeiden, dass in zwei Zweigen gleichzeitig am selben Modul gearbeitet wird - dann treten keine Konflikte auf \ Zusammenführungsprobleme.

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

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

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 weiterentwickeln. Aber ich glaube nicht, dass wir unsere Prozesse / Tools / so weiter aufgeben müssen, nur weil X (und / oder Y und / oder Z) gesagt haben, dass sie nicht mehr veraltet sind :-)

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 zu Trivialzwecken eingesetzt hat (im Allgemeinen nur zum Verzweigen von Veröffentlichungen).

Die meisten Orte, an denen ich gearbeitet habe, verlassen sich auf relativ schnelle Eincheckvorgänge und eine schnelle Erkennung / Lösung von Kollisionen. Dank der agilen Methodik können Sie Probleme schneller lösen, wenn Sie sie bemerken, während beide Parteien aktiv an diesen Code denken.

Auf der anderen Seite habe ich git nicht viel benutzt und vielleicht hat die Aufnahme des git-Tags diese Antworten beeinflusst. Ich verstehe, dass Branch / Merge bei git eine Selbstverständlichkeit ist, weil es so einfach ist.

Ja, Sie sollten Zweige verwenden, um alle (zumindest mittleren) Entwicklungsaufwände zu isolieren. Siehe " Wann sollten Sie verzweigen? ".

Das Problem ist eher die Verwendung von Schnellvorlaufzusammenführungen (die einen Zweigverlauf innerhalb eines anderen enthalten), vorausgesetzt, Sie drücken zuerst alle "Intermediate Checkpoint Commits" (die im Falle eines Rollbacks oder eines Rollbacks ein Problem sein können git bisect).
Weitere Informationen zum Unterscheiden von privaten Zweigen (die nicht zum Pushen bestimmt sind) von öffentlichen Zweigen finden Sie unter " Grundlegendes zum Git-Workflow ". Diese werden durch Zusammenführen (Fast-Forward-Zusammenführen) abgeschlossen, sofern Sie in dem Zweig, den Sie zusammenführen, die erforderliche Bereinigung vornehmen .
Siehe auch " Warum verwendet Git standardmäßig das Schnellvorlauf-Zusammenführen? ".

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

• Sie können Ihre Arbeit jederzeit einchecken, wenn Sie Bedenken haben, die Arbeit aufgrund eines HD-Ausfalls, eines Laptop-Verlusts usw. zu verlieren, und das Haupt-CI nicht beschädigt wird.
• Sie können weiterhin CI ausführen. Richten Sie einfach Ihr eigenes lokales CI ein, um Ihre Zweigstelle zu überwachen.
• Wenn die Funktion plötzlich in den Wartezustand versetzt wird (das passiert aber nie), können Sie sie einfach parken.

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

Wenn zwei Teams in ihrer eigenen Niederlassung arbeiten, werden die Änderungen der anderen Teams nicht angezeigt, auch wenn beide die masterNiederlassung integrieren . Das würde bedeuten, dass ihre Entwicklungszweige auseinander driften und wenn sich eines der Teams mit masterdem anderen zusammenschließen würde , müsste das andere Team viele Änderungen rückgängig machen.

Selbst wenn Sie Zweige für Features haben, würde ich Sie dringend bitten, alle Refactorings für den Master-Zweig zurückzuspielen und den Zweig nur für neue Features zu behalten.

• Backport-Refactorings

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 Big-Bang-Fusion stattfinden.

• Verwenden Sie Funktionsschalter

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

Die größeren Unternehmen verwenden alle eine auf Trunks basierende Strategie, bei der alle in der gleichen Branche arbeiten und der Aufbau und die kontinuierliche Integration von dieser Branche aus erfolgen. Die Vermeidung von Konflikten erfolgt durch Code-Modularisierung, Feature-Switching und clevere Tools. Das klingt schwierig, weil es so ist. Aber wenn Sie diese Debatte führen, dann, weil Sie den Fantasien der Menschen zum Verzweigen zum Opfer gefallen sind. Einige behaupten, sie verwenden hier das Insert-SCM-Tool mit einem vollständig Sarbanes-Oxley-konformen Verzweigungsmechanismus, und es ist alles brillant. Entweder lügen sie, täuschen sich selbst oder arbeiten nicht in der Größenordnung Ihres Systems.

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

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

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, in dem der SCM verwendet wird, um zu bestimmen, was in Ihr endgültiges Build fließ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 gerade bearbeitet und geht in Ihre wöchentliche Veröffentlichung ein. Modul B ist Modul A, enthält jedoch Projekt X und wird im selben Zweig bearbeitet, jedoch nicht in Ihr Release 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 mit dem Einfügen von Modul B zu beginnen.

Es wird eine Menge Weinen und Händewringen darüber geben. Was wäre wenn, und allgemeines Heulen. Dies ist die Ebene der Emotionen, die etwas so Einfaches wie ein Dateirepository umgibt, egal wie clever.

Aber es gibt deine Antwort.

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

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

Ich empfehle diese Art von Filialschema:

Release - Test - Entwicklung

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

Entwickler haben jeweils einen Zweig, mit dem sie routinemäßig spielen und von dort in den Entwicklungszweig integrieren können - idealerweise jeden Tag (sofern dieser kompiliert wird).

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

Wir tun Filialen nutzen, aber nicht auf granularer Ebene der Funktion. Wir verwenden Zweige für jeden Sprint. Verzweigungen sind im Wesentlichen keine schlechte Sache, da sie das Konzept des SOC in der Feature- oder Sprint-Ebene simulieren . 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.

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

Auf hoher Ebene machen sich Entwickler keine allzu großen Sorgen über das Zusammenführen mit der Hauptlinie, sondern verpflichten sich lediglich zur Zweigstelle. Ein (halb-) automatisierter Prozess prüft, welche Funktionen in die Hauptlinie aufgenommen werden sollen, führt diese Zweige zusammen und erstellt das Produkt. Der Prozess funktioniert, da wir diesen Prozess des Zusammenführens tatsächlich aus dem Issue-Tracker integrieren, sodass das Build-Tool weiß, welche Zweige zusammengeführt werden müssen.