Ich habe Entwicklerzweige gesehen, die in zwei Hauptszenarien verwendet wurden:
Die Open-Source-Community, in der diese Zweige tatsächlich als Repository-Forks fungieren, sodass Projektbetreuer den Zugriff auf das Master-Repository sperren und die Integration über Pull-Anforderungen erfordern können. Dies macht das Leben für Mitwirkende schwieriger, aber für die Betreuer viel einfacher, was natürlich genau der Punkt ist, und dies ist ein sehr erfolgreiches Modell auf GitHub.
Teams und Organisationen, die nicht durchgehend integriert sind und keine Erfahrung mit Instabilitäten in ihren Bereitstellungen oder, noch schlimmer, Instabilitäten in ihren Builds haben. Diese Teams versuchen im Allgemeinen, Entwicklerzweige zu verwenden, um die Stabilität der Hauptleitung zu schützen. Das Ergebnis ist - normalerweise - eine lange und sehr schmerzhafte Zusammenführungsperiode vor der Veröffentlichung, gefolgt von einer noch längeren und schmerzhafteren Stabilisierungsperiode, was manchmal der Fall ist passiert erst nach der Veröffentlichung.
Ich möchte nicht, dass Sie sich darüber aufregen, warum Sie CI benötigen, aber es ist klar, dass Sie wissen, dass Sie Ihre Änderungen nicht oft genug integrieren, deshalb macht es IMO keinen Sinn, um das Problem herumzutanzen.
Wenn Sie nicht in einem geografisch verteilten Team arbeiten, in dem Änderungen von externen Entwicklern "erfasst" werden müssen, ist das Branch-per-Developer-Modell nicht sehr sinnvoll. Das macht vor allem bei git keinen Sinn, da jeder Entwickler technisch bereits über ein eigenes Repository verfügt. Die meisten Organisationen sollten sich sehr häufig integrieren - etwa mehrmals pro Tag.
Ich gehöre derzeit zu einer Gruppe von ungefähr 35 Mitwirkenden, die in 4 separate Teams aufgeteilt sind. Die meisten Leute checken mindestens 2-3 Mal am Tag ein, manche Leute 10-15 Mal. Es ist ungewöhnlich, dass Builds gebrochen sind und extrem selten, dass sie länger als ein paar Minuten gebrochen bleiben. Git erledigt Zusammenführungen die meiste Zeit so mühelos, dass Remote-Entwicklerzweige nur unnötigen Overhead verursachen. Ziehen Sie es einfach, führen Sie es lokal zusammen und führen Sie Festschreibungstests durch, bevor Sie es verschieben. Es ist ganz einfach.
Wenn Sie unbedingt muss Integration, um die Stabilität des Master - Zweiges, das typische, bewährte Modell aufschieben zu schützen , ist eine verwenden Unstable - Zweig - manchmal genannt Entwicklungszweig , wie sie in den A erfolgreich Git Verzweigung Modell . Wenn Entwickler nicht erfolgreich in diese Branche zusammenführen können (was nur benötigt bauen , nicht einwandfrei laufen) mindestens einmal am Tag, dann haben Sie eine Qualität / Disziplin Problem und nicht eine Revisionskontrolle Problem; Wenn Sie das Problem durch nicht integrierte Entwicklerzweige vertuschen, wird das Problem nur verzögert, und wenn Sie dies tun, werden die möglichen Zusammenführungen viel schmerzhafter und instabiler, als sie wirklich sein müssen.
Feature-Zweige sind nicht die schlechtesten, aber IMO sind nur sehr wenige Projekte groß genug, um sie zu rechtfertigen. Wenn Ihr Projekt sehr umfangreich ist (dh Unmengen von Features, an denen gleichzeitig gearbeitet wird), erzielen Sie bessere Ergebnisse, wenn Sie es in separate autonome Komponenten aufteilen, als wenn Sie das Problem mit der Quellcodeverwaltung auf Papier bringen.
Sie können diesen Rat ignorieren , wenn Sie wollen, und viele Teams, aber einer der Gründe , das Verzweigungsmodell oben verbunden ist , so beliebt und erfolgreich ist , dass es an der Arbeit angefertigt mit Continuous Integration, nicht gegen sie.