Sollte ich erwarten, dass mein Team mehr als nur Grundkenntnisse in unserem Versionsverwaltungssystem besitzt?

Meine Firma ist vor ungefähr drei Monaten von Subversion zu Git gewechselt. Wir hatten Wochen vor dem Wechsel eine Vorankündigung. Da ich noch nie zuvor Git (oder ein anderes DVCS) verwendet hatte, las ich Pro Git und verbrachte ein wenig Zeit damit, meine eigenen Repositories zu spinnen und herumzuspielen, damit ich beim Wechsel mit minimalen Schmerzen weiterarbeiten konnte. Jetzt bin ich standardmäßig der "Git-Typ".

Mit ein paar Ausnahmen hat der größte Teil meines Teams noch keine Ahnung, wie Git funktioniert. Zum Beispiel stellen sie sich Zweige immer noch als vollständige Kopien des Quellcodes vor und gehen sogar so weit, das Repo in mehrere Ordner zu klonen (einen pro Zweig). Sie betrachten Git im Allgemeinen als eine beängstigende Blackbox.

Angesichts der grundsätzlichen Natur der Quellcodeverwaltung in unserer täglichen Arbeit (ganz zu schweigen von der lächerlichen Macht, die Git uns verleiht) bin ich der Meinung, dass jeder Entwickler, der kein bestimmtes Niveau an Kenntnissen damit erreicht, eine Verantwortung trägt .

Sollte ich von meinem Team erwarten, dass es zumindest ein wenig versteht, wie Git intern funktioniert und wie es über die grundlegendsten Pull / Merge / Push-Vorgänge hinaus verwendet wird? Oder mache ich nur etwas aus dem Nichts?

Professionalität würde natürlich bedeuten, dass ein Entwickler sich mit den Standardwerkzeugen seines Teams vertraut macht, auch wenn diese neu und ungewohnt (oder sogar unerwünscht) sind.

Ein paar Dinge in Ihrem Beitrag lassen mich jedoch innehalten.

Wir hatten Wochen vor dem Wechsel eine Vorankündigung.

Wochen? Das Austauschen der Quellcodeverwaltung ist eine große Sache. Es hätte Monate dauern müssen, bis eine solche Änderung eintrat.

Mit ein paar Ausnahmen hat der größte Teil meines Teams noch keine Ahnung, wie Git funktioniert.

Ihr Unternehmen hat also auf ein Quellcodeverwaltungssystem umgestellt, das zu diesem Zeitpunkt nur von wenigen, wenn überhaupt von irgendjemandem verstanden wurde?

Sofern es keinen anderen Kontext gibt, scheint der ganze Umzug schlecht durchdacht zu sein (der Umzug, nicht die Wahl - ich bin ein großer Fan von Schwänzen).

Wir haben Git dort eingeführt, wo ich arbeite, und es hat natürlich Widerstand gegeben. Es war für ein neues Projekt, daher unterhalten wir jetzt zwei Repositories.

Ein Teil des Problems besteht darin, dass die Benutzer die Vorteile eines Wechsels zu einem anderen SCM nicht erkennen, wenn der von ihnen verwendete für sie funktioniert. Es hat geholfen, als wir uns mit unserem Team für ein paar einstündige Sitzungen zusammengesetzt haben, in denen wir nur Anwendungsfälle aus unseren Projekten zeigten und wie Git es einfacher machte. Zum Beispiel die Dinge, die uns geholfen haben:

• Lokale Niederlassungen, um zum Experimentieren anzuregen
• Git-Halbierung zum einfachen Aufspüren von Fehlern
• häufige Commits ohne andere zu unterbrechen
• Schnelles Umschalten zwischen Zweigen

usw. Jedes dieser Probleme löste ein Problem, das wir mit unserem vorherigen SCM hatten und so konnten die Leute Git mehr schätzen.

Die andere Sache ist, dass man nicht erwarten kann, dass Leute davon ausgehen und Bücher darüber lesen, weil es nur sehr wenige tun. Vielleicht müssen sie ihre Arbeit erledigen, andere Aufgaben übernehmen oder aus einer Reihe von Gründen.

Als Git-Experte müssen Sie sich also hinsetzen und es den Leuten so einfach wie möglich machen, es zu benutzen. Sie möchten Code schreiben und nicht mit ihrem SCM-System herumspielen.

Git CLI ist kryptisch und triviale Probleme (für Sie und mich) blockieren die Arbeit von Menschen. Folgendes ist in unserem Team passiert (wohlgemerkt, das sind ziemlich kompetente Entwickler):

• Git mit SSH unter Windows war ein häufiges Problem.
• Die Leute würden ziehen, verschmelzen, aber die Verschmelzung nicht schieben. Das Diagramm wäre also ein riesiges Durcheinander
• Das Leistungsproblem unter Windows hat dazu geführt, dass "Git-Status" 15 Sekunden dauert
• Konnte nicht herausfinden, wie man einen neuen Zweig zieht. Sie würden einen "git checkout -b" machen, der von dem, woran sie gerade arbeiteten, abzweigt
• EGit in Eclipse hatte eine überwältigende Auswahl. Es endete damit, dass jeder zuerst die Kommandozeile benutzen sollte
• Basierend auf dem vorherigen Element, Zusammenführen und Einrichten von Git Mergetool
• Verwirrt über die Unterschiede zwischen "git add" und "git commit" und "git push".

Wir bekommen immer noch Widerstand, aber die Leute können die Vorteile definitiv erkennen. Es ist sehr wichtig, ein paar Git-Leute zur Orientierung zu haben und bereit zu sein, mitzuhelfen. Außerdem würde ich es vermeiden, coole Dinge wie reset / rebase / - amend / etc zu lehren. Da die meisten Leute Git wie SVN verwenden, ist es besser, sie es entdecken zu lassen, wenn sie dies wünschen.

Kompetent gegen Git-Mania

Ein Begriff wie Grundkenntnisse kann für verschiedene Menschen verschiedene Bedeutungen haben. Viele Leute scheinen Git-Manie zu haben (nicht, dass daran etwas falsch ist). Viele von uns wurden durch die Schlamperei unserer eigenen und anderer Leute mit der Quellcodeverwaltung schwer verbrannt.

Warum es wichtig ist (so viel)

Tools zur Quellcodeverwaltung sind von entscheidender Bedeutung, da durch Missbrauch nicht nur eine Person, sondern ein ganzes Team gebremst werden kann. Der Missbrauch von Git sollte weniger problematisch sein als der Missbrauch von SVN, CVS und anderen Systemen. In der Vergangenheit war die unpassende Verwendung von Systemen, die Dateien sperrten, besonders problematisch, und Unternehmen stellten diskrete Build-Teams ein, so dass es einen fließenden Experten gab, der fast nur die Quellcodeverwaltung durchführte, um die Wunde im Repository zu heilen. Dies erklärt zum Teil etwas von der Leidenschaft, die Sie hinter git finden.

Wie sieht Grundkenntnisse aus?

Einige konkrete Kriterien sind:

• Ohne Hinweis auf Dokumentation:

  • Kann Dateien hinzufügen, Änderungen festschreiben, Aktualisierungen verschieben und abrufen.
  • Kann den Status und die Revisionsaktivität anzeigen.
  • Kann schnell und fehlerfrei verzweigen und zusammenführen.
  • Kann Kasse entsprechend verwenden.
  • Erstellen Sie Festschreibungskommentare, die die Kriterien der Gruppe für Kommentare erfüllen.
  • Diff wechselt zwischen Arbeitskopie und Archiv.

• Mit Dokumentation:

  • Fügen Sie Benutzer und Anmeldeinformationen für das lokale Repository hinzu.
  • ein lokales Repo einleiten.
  • Remote Repo verwalten.
  • Ignorierte Dateien konfigurieren, öffentliche / private PKI-Schlüsselpaare generieren.
  • Dateien verschieben und löschen.
  • Verwenden Sie Bisect, um die Änderung zu finden, die einen bestimmten Fehler verursacht hat.

Ein solides mentales Modell von git und dem verwalteten Code ist entscheidend, um Fehler zu vermeiden.

Was würden Sie für fortgeschrittene Kenntnisse hinzufügen?

Fließender Gebrauch ist für Entwickler und möglicherweise einige andere Mitglieder Ihres Teams von wesentlicher Bedeutung. Tools wie Git sind Overhead-Tools und sollten so weit erlernt werden, dass sie nahezu automatisch ablaufen können. Das Minimieren von Zeit und Ablenkung, die durch die Verwendung von Git-Befehlen erzeugt werden, die tausende Male pro Jahr wiederholt werden, hat einen hohen Wert.

Es wird immer einige Mitglieder Ihres Teams geben, die Power-User sind und fast jeden Befehl mit fast jeder Option verwenden. Meine Empfehlung ist, dass die Teammitglieder dazu ermutigt werden, Git (und andere Tools) so lange zu lernen, bis der ROI für das Lernen unter den Wert fällt, der für die Durchführung anderer Projekte anfällt Sprint.

GIT ist ein gerechtes Werkzeug, um einen Job zu erledigen, und eines der größten Probleme besteht darin, dass viele GIT-Evangelisten erwarten, dass alle GIT-Benutzer Experten werden, die die feinsten Punkte verstehen, wie es funktioniert. Dies ist die größte Schwäche von GIT - um es zu nutzen, muss man wissen, wie es funktioniert. Es gibt keine Rezepte mit GIT, von Ihnen wird erwartet, dass Sie ein GIT-Experte sind oder es nicht verwenden. Es ist großartig, dass Sie Pro-GIT lesen. Ihre Organisation benötigt einen GIT-Guru (oder zwei), um die Investition zu maximieren, denn nicht jeder Entwickler möchte ein GIT-Guru werden - und das ist in Ordnung.

Das Team muss wissen, wie GIT verwendet wird (in der Tat muss es nur wissen, wie die Teile von GIT verwendet werden, die vom Workflow benötigt werden), nicht wie GIT funktioniert. Es ist schädlich zu erwarten, dass jeder Entwickler jedes Detail über jedes von ihm verwendete Tool kennt. Wenn Sie kein Rezeptbuch haben, das Ihren Workflow unterstützt, haben Sie GIT nicht bereitgestellt, sondern auf die Entwickler kopiert.

Ich gebe keinen Affen, wie GIT funktioniert, solange ich weiß, wie man GIT für mich funktioniert.

Ja.

Unabhängig davon, für welches Tool sich das "Unternehmen" entschieden hat, sollte Ihr Entwicklungsteam einige Zeit damit verbringen, den richtigen Umgang mit dem Tool zu erlernen. Nichts schadet der Produktivität mehr als ein Haufen Entwickler, die Angst vor einem Tool haben oder es nicht kennen. Wenn sie es falsch benutzen oder dagegen arbeiten, treten Probleme auf und Sie werden als "go to guy" damit beauftragt, das Chaos zu beseitigen.

Git ist für viele ein schwieriger Übergang, daher kann eine obligatorische Sitzung zum Hinsetzen angebracht sein. Dies sollte dazu beitragen, viele der Probleme, die die Menschen haben, zu lösen.

Ich habe Git nur in einer persönlichen Umgebung und nicht in einer professionellen Umgebung verwendet, und obwohl mir die Leistungsfähigkeit und die Idee einer dezentraleren Quellcodeverwaltung gefallen, gibt es große Probleme. Git hat eine undichte Abstraktion und es sind mehrere Befehle erforderlich, um einfache Dinge zu tun (zum Beispiel, um eine Änderung vorzunehmen: git add, git commit, dann git push). Außerdem fehlt ein Teil der Dokumentation und / oder ist verwirrend, wie bei der Beschreibung des Rebase-Befehls ... "Lokale Weiterleitungs-Commits an den aktualisierten Upstream-Head". Ich habe keine Ahnung, was das bedeutet, und obwohl ich jetzt weiß, dass Sie Commits verschieben und damit die Geschichte neu schreiben können (ein weiteres Ärgernis ... warum sollten Sie dies tun dürfen ???), hätte ich das von diesem Befehl niemals erraten Beschreibung. Ich denke, ein bisschen Lesen seitens Ihres Teams und ein bisschen mehr Training von Ihnen ist angebracht.

Schulung und Verständnis sind die Mindestanforderungen. Jemand, der dafür verantwortlich ist, hätte sicherstellen müssen, dass ein Plan vorhanden ist, wie Ihr Team ihn verwenden soll. Ohne Richtlinien würden Sie keine neue Programmiersprache übernehmen. Das Fahrertraining ist viel effektiver, wenn festgelegte Verkehrsregeln berücksichtigt werden.

Nein; Ich halte es für vernünftig, Folgendes zu erwarten:

1. Führen Sie alltägliche Aufgaben (Festschreiben, Drücken, Ziehen, Verzweigen, Zusammenführen, Halbieren usw.) aus, ohne die Hand zu halten.
2. Führen Sie nicht routinemäßige Aufgaben ohne wiederholte Anweisung aus. (Ein paar Wiederholungen sind in Ordnung - ich muss jemanden 2-3 Mal treffen, bevor sein Name wirklich bleibt.)

Wenn sie # 1 nicht schaffen, war der Trainingsteil Ihres Roll-outs wahrscheinlich unzureichend. Wenn sie Nr. 2 nicht können, stellen Sie zunächst sicher, dass Sie die Dinge klar genug erklären, bevor Sie sich zu sehr aufregen.