it-swarm.com.de

Codeüberprüfungsprozess bei Verwendung von GIT als Repository?

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

Aktueller Prozess:

  • Wir haben einen GIT-Server mit einem master -Zweig, zu dem sich jeder verpflichtet
  • Entwickler arbeiten mit dem lokalen master Spiegel oder einem lokalen Feature-Zweig
  • Entwickler Push zum master Zweig des Servers
  • Überprüfung des Anforderungscodes durch 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 ein paar Stunden verbrannt, um herauszufinden, was passiert ist ...

Also möchten wir

  • Codeüberprüfung VOR der Übermittlung an den 'Master'.
  • Haben Sie einen Prozess, der mit einem globalen Team funktioniert (nein über die Schulter Bewertungen!)
  • etwas, das nicht erfordert, dass sich ein einzelner Entwickler an seinem Schreibtisch/seiner Maschine befindet, um eingeschaltet zu werden, damit jemand anderes fernsteuern kann (menschliche Abhängigkeit beseitigen, Entwickler gehen zu verschiedenen Zeitzonen nach Hause).

Wir verwenden TortoiseGIT für eine visuelle Darstellung einer Liste geänderter Dateien, unterschiedlicher Dateien usw. Einige von uns wechseln in eine GIT-Shell, wenn die GUI nicht ausreicht. Idealerweise möchten wir jedoch, dass der Workflow einfach und GUI-basiert ist (Ich möchte, dass das Tool jede Last lindert, nicht meine Entwickler).

8
DeepSpace101

Ein einfaches, aber effektives Modell ist das Modell GitHub-Pull-Anfrage , bei dem die Mitwirkenden die Anfragen "Bitte in meinem Code zusammenführen" einreichen. 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 an den Hauptzweig pushen (dies kann an Ihren Geschmack angepasst werden, wir erlauben "kleinere" Commits, direkt einzusteigen).

15

Git ist ein verteiltes Versionskontrollsystem: Haben Sie 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 aus seinem Zweig/Repo in den Master gezogen.

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

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


Lernen Sie auch die Umgangssprache: Mit "Entwickler verpflichten sich zum Master-Zweig des Servers" meinen Sie, dass sie Push ihre Änderungen am Master vornehmen?

1