Was ist der beste Prozess für die Codeüberprüfung bei Verwendung von GIT? Wir haben einen externen GIT-Anbieter (Unfuddle) und haben Obergrenzen für die Ressourcennutzung. Daher können wir nicht für jeden Entwickler dedizierte Remote-Repositorys haben.

Aktueller Prozess:

  • Wir einen GIT-Server mit einem master -Zweig haben, zu dem sich jeder verpflichtet
  • Entwickler arbeiten über den lokalen master -Spiegel oder a Zweig für lokale Funktionen
  • Entwickler pushen auf Server „s master Zweig
  • Überprüfung des Anforderungscodes für Entwickler beim letzten Festschreiben

Problem:

  • Jeder Fehler in der Codeüberprüfung ist bereits im Master, wenn er abgefangen wird.
  • Schlimmer noch, normalerweise hat jemand einige Stunden beim Versuch gebrannt um herauszufinden, was passiert ist …

Wir möchten also, dass

  • vor der Übermittlung an den „Master“ eine Codeüberprüfung durchführt.
  • Haben Sie einen Prozess, der mit einem globalen Team zusammenarbeitet (keine über die Schulter -Bewertungen!)
  • , für den kein einzelner Entwickler an seinem Schreibtisch / seiner Maschine sitzen muss eingeschaltet sein, damit jemand anderes i n (menschliche Abhängigkeit beseitigen, Entwickler gehen zu verschiedenen Zeitzonen nach Hause)

Wir verwenden TortoiseGIT zur visuellen Darstellung einer Liste geänderter Dateien, unterschiedlicher Dateien usw. Einige von uns fallen in eine GIT-Shell, wenn die GUI nicht ausreicht, aber im Idealfall möchten wir, dass der Workflow einfach und GUI-basiert ist (ich möchte, dass das Tool keine Belastung verursacht, nicht meine Entwickler).

Kommentare

  • Führen Sie vor dem Festschreiben einen Komponententest durch?
  • @GuyCoder: Meistens tun wir das.
  • Wenn Ihr Host keine Codeüberprüfung bereitstellt Fähigkeit, einen besseren Gastgeber zu bekommen. Schauen Sie sich Gerrit an und prüfen Sie, ob Sie einen Host finden, der ihn bereitstellt.

Antwort

A. Ein einfaches, aber effektives Modell ist das GitHub-Pull-Request-Modell , bei dem die Contributors-Datei „Bitte in meinem Code zusammenführen“ -Anfragen. Ein Betreuer überprüft die Änderungssätze und entscheidet, ob sie mehr Arbeit benötigen oder zum Zusammenführen geeignet sind. Er kann dann in den Hauptzweig übergehen. Committer dürfen im Allgemeinen nicht direkt in den Hauptzweig pushen (dies kann an Ihren Geschmack angepasst werden, wir erlauben „kleinere“ Commits direkt).

Kommentare

  • Wir haben ein enges Team von 7 professionellen Entwicklern (im Vergleich zu anonymen Mitwirkenden) weltweit, daher ist es sicher, dass jeder direkt an unseren Remote-Master weitergeleitet wird. Obwohl es ' ein Link + Intro gegen eine eigenständige Antwort ist, die ich bevorzuge, ist es in diesem Fall sinnvoll. Tolles Schreiben unter Link, danke!
  • @Sid Mit einem 3-köpfigen Team würde ich ' nicht zulassen, dass sie alle zum Meister drängen.
  • Pull-Anfragen sind auch in Rhodecode und Atlassian Stash verfügbar.
  • @Andrew: Warum nicht? Es gibt viele Probleme, die entstehen können, wenn die gesamte Teamarbeit über einen Choke-Punkt geleitet wird. Diese können alle gemildert werden, aber eine Einzelpunkt-Befehls- und Kontrollstruktur ist für einige Situationen besser geeignet als für andere.

Antwort

Git ist ein verteiltes Versionskontrollsystem: Es gibt nicht nur ein Repo mit einem Zweig!

Sie können mehrere Repositorys einrichten – eines für jeden Entwickler – und eines für das Master-Repo. Wenn einer ihrer Zweige zum Zusammenführen bereit ist, fordert der Entwickler eine Zusammenführung an und seine Änderungen werden von seinem Zweig / Repo in den Master übernommen.

Bevor diese Zusammenführung tatsächlich stattfindet, kann der Prüfer die Änderungen übernehmen Überprüfen Sie die Umgebung und überprüfen Sie sie, bevor Sie sie an den Master senden.

Weitere Vorteile sind, dass ein Entwickler auf diese Weise so viele Zweige haben kann, wie er möchte, mit dem Namen, wie er möchte, ohne sich gegenseitig zu stören oder gar zu stören um die schmutzige Wäsche des anderen so oft zu sehen.

Lernen Sie auch die Umgangssprache: Mit „Entwickler verpflichten sich zum Hauptzweig des Servers“ meinen Sie, dass sie pushen ihre Änderungen an Master?

Kommentare

  • Ja, sie push ihre Arbeit. ' kann keine eindeutigen Remote-Repositorys auf dem GIT-Server haben, da wir einen GIT-Hoster bezahlen und diese pro Repository berechnen. Meinten Sie mehrere Remote-Filialen pro Entwickler? Und wenn Sie the reviewer can pull the changes into their environment sagen, welche genauen GIT-Befehle (oder TortoiseGIT-Flow) meinen Sie?
  • Nein, ich meine, Sie haben mehrere Repositorys. eine pro Entwickler, und in diesem Repository können sie so viele Zweige haben, wie sie möchten. Was pull betrifft, weiß ich ' nicht, wie der Befehl in TortoiseGIT lauten würde – aber der Befehl lautet Git Pull . ' ist das Gegenteil eines Pushs – Sie ziehen Änderungen aus dem Remote-Repository, um Ihre Umgebung mit Arbeiten zu aktualisieren, die andere Entwickler möglicherweise ausgeführt haben.
  • Ich kenne git pull 🙂 …Ich habe nach der vollständigen Syntax gefragt, um das Repo / Branch / Tag-System auf Push / Pulls zu überprüfen, auf die Sie sich beziehen. Im Moment machen wir sowieso git pull, ' ist direkt von remote: master entfernt – was die Probleme verursacht. Wie auch immer, die Links von Steven ' waren großartig. Vielen Dank
  • Für alle praktischen Zwecke in diesem Fall ist ein Zweig im gehosteten Repo genauso wie ein anderes Repo.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.