it-swarm.com.de

Änderungen vom Master in meinen Arbeitsbereich ziehen?

Wir arbeiten zu zweit an etwas. Wir verwenden diese Zweigstruktur

  • meister
  • dev-A
  • dev-B

Wir arbeiten beide an separaten Zweigen (dev-A, B) und wann immer wir fertig sind, fördern wir unsere Änderungen zum Master.

Der Nachteil dabei ist jedoch, dass wir keine Änderungen erhalten können, die der andere Entwickler vornimmt. Alles ist im Master-Baum vorhanden - aber wir können nicht die neuesten Updates erhalten, die der andere Entwickler vorgenommen hat.

Gibt es eine Möglichkeit, dies zu beheben, oder sollten wir unsere Zweigstruktur ändern (pro Feature?)?

17
Utkarsh Sinha

Ich habe Entwicklerzweige gesehen, die in zwei Hauptszenarien verwendet wurden:

  1. Die Open-Source-Community, in der diese Zweige tatsächlich Repository-Gabeln sind, sodass Projektbetreuer den Zugriff auf das Master-Repository sperren und die Integration durch 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.

  2. Teams und Organisationen, die keine kontinuierliche Integration und eine Erfolgsgeschichte der Instabilität in ihren Bereitstellungen oder, schlimmer noch, der Instabilität in ihren Builds aufweisen. 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, die manchmal passiert erstnachder Veröffentlichung.

Ich möchte nicht, dass dies ein Scherz darüber ist, warum Sie CI benötigen, aber aus Ihrer Frage geht hervor, dass SieknowIhre Änderungen nicht oft genug integrieren, sodass IMO keinen Sinn macht um das Thema herum tanzen.

Wenn Sie nicht tatsächlich in einem geografisch verteilten Team arbeiten und Änderungen von externen Entwicklern "steuern" müssen, ist das Branch-per-Developer-Modell nicht sehr sinnvoll. Besonders mit git macht es keinen Sinn, weil jeder Entwicklerschontechnisch sein eigenes Repository hat. Die meisten Organisationen sollten sich sehr häufig integrieren - wie in, mehrmals täglich.

Ich bin derzeit Teil 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, einige Leute 10-15 Mal. Es ist ungewöhnlich, dass Builds kaputt sind und es äußerst selten vorkommt, dass sie länger als ein paar Minuten kaputt bleiben. Git verarbeitet Zusammenführungen die meiste Zeit so mühelos, dass Remote-Entwicklerzweige nur unnötigen Overhead verursachen. Einfach ziehen, lokal zusammenführen und Commit-Tests ausführen, bevor Sie Push ausführen. Das ist ganz einfach.

Wenn Sie die Integration unbedingtmüssenverschieben, um die Stabilität des Hauptzweigs zu schützen, besteht das typische, bewährte Modell darin, eineninstabilen Zweig- zu verwenden, der manchmal als a bezeichnet wirdEntwicklungszweig, wie in beschrieben. Ein erfolgreiches Git-Verzweigungsmodell . Wenn Entwickler nicht mindestens einmal am Tag erfolgreich in diesen Zweig einbinden können (der nurbuild, nicht fehlerfrei ausgeführt werden muss), liegt ein Qualitäts-/Disziplinproblem und kein Problem der Revisionskontrolle vor ;; Das Vertuschen durch die Verwendung nicht integrierter Entwicklerzweige verschiebt das Problem nur und macht die eventuellen Zusammenführungen dadurch 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 groß ist (d. h. Tonnen von Funktionen werden gleichzeitig bearbeitet), sehen 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 möchten, und viele Teams tun dies. Einer der Gründe, warum das oben verlinkte Verzweigungsmodell so beliebt und erfolgreich ist, ist, dass es so konzipiert ist, dass esmitkontinuierlicher Integration funktioniert, nicht dagegen es.

16
Aaronaught

In Ihrer Arbeitsbranche, wenn Sie gehen:

git commit -am "Committing changes before merge"
git merge master

sie können auch aus dem anderen Entwicklerzweig zusammenführen

git checkout dev-A
git merge dev-B

Das wird zusammenführen die Änderungen im Master in Ihrem Entwicklungszweig.

16
scaryrawr

Wenn dev-A und dev-B unterschiedliche Zweige für unterschiedliche Projekte sind, ist die Antwort von @scaryrawr am besten.

Wenn dev-A und dev-B tatsächlich genau derselbe Code (dasselbe Projekt) sind, besteht eine Alternative darin, dass beide in einem der Zweige arbeiten. Zum Beispiel erstellen Sie einen Abzweig-Master namens 'devWork'. Sie beide checken devWork aus, arbeiten daran, schreiben Änderungen fest und übertragen sie. Übertragene Änderungen befinden sich nicht auf dem Master, sondern in devWork. Dann müssen die anderen Benutzer des Zweigs einfach lokal einen PULL-Vorgang ausführen, um Push-Änderungen zu erhalten.

Sie können dann Standardmethoden befolgen, um die Arbeit an devWork wieder an Master usw. zu erledigen.