Verzweigung (Versionskontrolle)
Verzweigung, in Versionskontrolle und Software -Konfigurationsverwaltung, ist die Duplizierung eines Objekts unter Versionskontrolle (wie z. Quellcode Datei oder a Verzeichnisbaum). Jedes Objekt kann danach separat und parallel modifiziert werden, so dass die Objekte unterschiedlich werden. In diesem Zusammenhang werden die Objekte aufgerufen Geäst. Die Benutzer des Versionskontrollsystems können jeden Zweig verzweigen.
Zweige sind auch bekannt als als Bäume, Ströme oder Codelines. Der ursprüngliche Zweig wird manchmal als die genannt Elternzweig, das Ströme Branch (oder einfach stromaufwärts, insbesondere wenn die Zweige von verschiedenen Organisationen oder Einzelpersonen aufrechterhalten werden) oder der Back -Stream.
Kinderzweige sind Zweige, die einen Elternteil haben; Ein Zweig ohne Elternteil wird als der bezeichnet Rüssel oder der Hauptlinie.[1] Der Kofferraum wird manchmal auch lose als Kopf bezeichnet, bezieht sich jedoch nicht auf einen Zweig, sondern auf den jüngsten Commit in einem bestimmten Zweig, und sowohl der Kofferraum als auch jeder benannte Zweig hat seinen eigenen Kopf. Der Kofferraum soll normalerweise die Basis eines Projekts sein, auf dem die Entwicklung fortschreitet. Wenn Entwickler ausschließlich am Kofferraum arbeiten, enthält es immer die neuesten innovativ, auf dem neuesten Stand Version des Projekts, kann jedoch auch die instabilste Version sein. Ein anderer Ansatz besteht darin, einen Zweig vom Kofferraum zu teilen, Änderungen in dieser Zweigstelle umzusetzen und die Änderungen wieder in den Kofferraum zu verschmelzen, wenn sich der Zweig als stabil erwiesen und funktioniert. Abhängig vom Entwicklungsmodus und verpflichten Richtlinie Der Kofferraum kann die stabilste oder die am wenigsten stabilste oder etwas zwischeneinander. Andere Begriffe für den Kofferraum sind einzuziehen Grundlinie, Hauptlinie, und Meister, In einigen Fällen werden diese jedoch mit ähnlichen, aber unterschiedlichen Sinnen verwendet - siehe Versionskontrolle § gemeinsame Terminologie. Oft findet die Hauptarbeiten für die Hauptentwickler im Kofferraum statt und stabile Versionen werden verzweigt, und gelegentliche Fehlerfixe werden von Zweigen zum Kofferraum verschmolzen. Wenn die Entwicklung zukünftiger Versionen in Nicht-Stick-Filialen erfolgt, wird normalerweise für Projekte durchgeführt, die sich nicht häufig ändern, oder wenn eine Änderung erwartet wird, dass sich die Entwicklung noch lange entwickelt, bis sie für die Einbeziehung in den Kofferraum bereit sind.
In einigen Verteilte Revisionskontrollsysteme, wie zum Beispiel DarcsEs gibt keine Unterscheidung zwischen dazwischen Repositorys und Zweige; In diesen Systemen entspricht das Abnehmen einer Kopie eines Repositorys der Verzweigung.
Die Verzweigung impliziert im Allgemeinen auch die Fähigkeit zu später verschmelzen oder integrieren wechselt wieder in den übergeordneten Zweig. Oft werden die Änderungen zum Kofferraum zurückgeführt, auch wenn dies nicht der übergeordnete Zweig ist. Ein Zweig, der nicht zusammengeführt werden soll (z. B. weil er es war Relizenz unter einer inkompatiblen Lizenz durch Dritte, oder es versucht, einem anderen Zweck zu dienen) wird normalerweise als a genannt Gabel.
Motivationen für die Verzweigung
Zweige ermöglichen es, Teile der Software parallel zu entwickeln.[2] Große Projekte erfordern viele Rollen, einschließlich Entwicklern, Baumanagern und Qualitätssicherung Personal. Darüber hinaus müssen möglicherweise mehrere Releases auf verschiedenen Betriebssystemplattformen beibehalten werden. Zweige ermöglichen es Mitwirkenden, Änderungen zu isolieren, ohne die Codebasis zu destabilisieren, z. B. Korrekturen Für Fehler, neu Merkmale,[3] und Versionen Integration. Diese Änderungen können später sein zusammengeführt (neu synchronisiert) nach dem Test.
Entwicklungszweig
A Entwicklungszweig oder Entwicklungsbaum von einer Software ist eine Version, die unter sich ist Entwicklungund war noch nicht offiziell gewesen veröffentlicht. In dem Open Source Community, der Begriff der Freigabe ist in der Regel metaphorisch, da in der Regel jemand eine gewünschte Version überprüfen kann, unabhängig davon, ob sie sich in der Entwicklungszweig befindet oder nicht. Oft wird die Version, die irgendwann die nächste wird Haupt Version heißt das Entwicklungszweig. Es gibt jedoch häufig mehr als eine nachfolgende Version der Software zu einem bestimmten Zeitpunkt.
Einige Revisionskontrollsysteme verfügen über spezielle Jargon für die Hauptentwicklungszweig. Zum Beispiel in Lebenslauf, es wird der "Haupt" -Ast genannt; in Git Es wird in der Regel als "Haupt" bezeichnet ("Master" war früher häufig), obwohl die Software kein bestimmter Zweigname benötigt.[4][5] Ein generischer Begriff ist "Trunk".
Schatten- oder magische Zweige
Im CVSNT, a Schatten oder Magie Zweig-Schatten-Änderungen im vorgelagerten Zweig, um die Aufrechterhaltung kleiner Änderungen zu erleichtern (CVC ist ein Open-Source-Paketbuilding-System, das ein Revisionskontrollsystem für Pakete enthält, die von durch erstellt wurden rpath.))
Repository -Klone
Im Distributed Revision ControlDas gesamte Repository mit Zweigen kann kopiert und weiter gearbeitet werden. Monoton (MTN), Quecksilber (hg) und Git Nennen Sie es "Klon"; Basar nennt es "Zweig".
Siehe auch
Verweise
- ^ Berczuk, Steve; Appleton, Brad (2003). Software -Konfigurationsverwaltungsmuster: effektive Teamarbeit, praktische Integration. Addison-Wesley. ISBN 0-20174117-2. Abgerufen 2007-05-24.
- ^ Appleton, Brad; Berczuk, Stephen; Cabrera, Ralph; Orenstein, Robert (1998-02-08). "Streamed Lines: Verzweigungsmuster für die Entwicklung paralleler Software" (PDF). Hang. Abgerufen 2009-08-12.
- ^ Bailey, Derick (2009-07-15). "Teil 1: Warum". Zweig-per-Feature-Quellenkontrolle. Los Techies. Abgerufen 2009-08-12.
- ^ Wallen, Jack (2020-09-22). "Github, um den Master ab Oktober durch den Main zu ersetzen: Was Entwickler jetzt tun müssen". TechRepublic. Abgerufen 2022-04-24.
- ^ Heinze, Carolyn (2020-11-24). "Warum Github seine Master -Filiale in Main umbenannt hat". Theserverside. Abgerufen 2022-04-24.