Kontext

Mein Team von 8 Ingenieuren wechselt derzeit zu Git (von Subversion) für unser nächstes großes Ding. Wir haben eine Handvoll "erfahrener" Ingenieure, die es ziemlich schwierig finden, Git zu erlernen. Die gleichen einfachen Fragen werden mir gestellt, obwohl ich Benutzerhandbücher, Schulungsaktivitäten und Whiteboard-Sitzungen zur Verfügung gestellt habe. Wir hatten zwei Juniorberater, die in ein paar Tagen alles in den Griff bekommen haben, und es hat wirklich ein Licht auf das Thema geworfen. Dies ist kein Muster, das auf Git beschränkt ist, aber es ist dadurch sichtbar geworden.

Frage

Ich fühle mich Ingenieuren, die nicht lernen können / wollen, nicht besonders wohl - insbesondere Mitarbeitern mit dem hier vorhandenen Dienstalter. Ich möchte jedoch, dass das Team erfolgreich ist und ein großartiges Produkt entwickelt. Wir verwenden ein zentrales Git Flow-Modell, und ich glaube, die neue Terminologie verwirrt sie.

Kann ich diesen Mitarbeitern helfen, Git zu lernen?

Sourcetree ist der Client, der vom gesamten Team verwendet wird.

Gib ihnen ein Spielzeug.

Git ist schwer. Vor allem, wenn Sie die Quellcodeverwaltung in einem anderen Paradigma durchgeführt haben. Ich habe den Build abgebrochen, als ich zum ersten Mal versucht habe, mit git zu arbeiten. Es machte mich so paranoid, dass ich nicht einchecken wollte, bis alles erledigt war. Ich habe Versionen in Ordnern versteckt. Dann habe ich endlich herausgefunden, was ich brauche, um daran vorbeizukommen:

Ich brauchte einen sicheren Ort zum Spielen.

Sobald ich das hatte, verursachte ich absichtlich Probleme, damit ich lernen konnte, wie man sie behebt - alles an meinem sicheren Ort. Ich entwickelte ein Muster, das ich verwenden konnte, auch wenn es unterbrochen wurde, und trotzdem in einen guten Zustand zurückkehrte. Es dauerte nicht lange, bis Leute zu mir kamen, um mir bei der Arbeit zu helfen. Alles nur, weil ich mir die Zeit genommen habe, mit einem Spielzeug zu spielen.

Wenn Sie sie einfach in die Tiefe werfen, haben Sie Glück, wenn sie schweben.

Der durchschnittliche Entwickler benötigt nicht viele Goodies von Git. Es ist ein verteiltes Quellcodeverwaltungssystem, aber die meisten Teams werden es mit einem zentralen kanonischen Repo zum Drücken und Ziehen verwenden.

Die wichtigsten Befehle, die Ihr Team benötigen wird, sind:

• Änderungen aus der Ferne abrufen und zusammenführen und daraus resultierende Konflikte behandeln (möglicherweise erneutes Basieren)
• Commit und Push-Commits an Remote (oder Push an Staging-Repo / -Zweig, um die Änderungen nach Überprüfung in Main zu übernehmen)
• Zur Unterstützung: Beheben Sie das Chaos, nachdem Sie etwas falsch gemacht haben.

diejenigen, die die fortgeschritteneren Benutzer benötigen, sind

• lokale Commits abwickeln
• Filialen verwalten

Für Leute, die mit git nicht vertraut sind und die es nicht lernen wollen, richten Sie ein paar schnelle Alias-Befehle ein, um sie auszuführen und sicherzustellen, dass alles korrekt ist (fügen Sie neue Dateien hinzu, entfernen Sie gelöschte Dateien aus dem Repo usw.).

Stellen Sie sicher, dass diese gut dokumentiert und anständig narrensicher sind.

Dies ist im Sinne des xkcd-Comics , merken Sie sich einfach die Befehle und hoffen Sie, dass die Dinge nicht zu sehr durcheinander geraten, wenn Sie einen Fachmann fragen.

Lassen Sie sie eine Git-Benutzeroberfläche verwenden.

Wenn sie Erfahrung mit TortoiseSVN haben, funktioniert TortoiseGit (nur Windows) fast genauso. Ansonsten ist SourceTree (Windows + Mac) wunderbar - wir haben mehrere Nicht-Entwickler-QS, die dank SourceTree problemlos komplexe Aufgaben in Git bewältigen konnten.

Diese Antwort versucht herauszufinden, wie man Senior-Programmierer interessiert gitund nicht, wie man gitam schnellsten lernt - dafür ist das exzellente Git-Buch großartig oder eine beliebige Anzahl von Tutorials (=> Google). Gute Links zu dieser Antwort sind Git ist eine rein funktionale Datenstruktur oder insbesondere das kurze How Git, das Ihre Daten speichert .

Ich fürchte, ich sehe das eher düster. Ich war genau in Ihren Schuhen - ich bin ein gitNerd und wollte ein Team von svnwinzigen Ergebnissen abbringen, seien wir ehrlich. In meinem Fall hat es dazu geführt, dass ich meine eigene Wahrnehmung aktiv ändere und akzeptiere, dass Menschen einfach nicht "zum Glück gezwungen" werden können. Menschen sind keine Computer, es ist unglaublich schwer, sie zu programmieren. Ich bin immer noch froh, dass ich es versucht habe, es hat mir auf sanfte Weise gezeigt, was ich tue und was ich in meinem Berufsleben nicht tun möchte.

Es gibt Leute, die beginnen sich zu motivieren, wenn es um neue Dinge geht, und es gibt Leute, die demotiviert sind. Das hat nichts damit zu tun git, aber gitspeziell haben Sie immer den Effekt "Warum sollten wir es überhaupt verwenden, wenn svnes in Ordnung ist?", Was eine massive psychologische Barriere darstellt.

Tollkühnheit gitsetzt auch ein intensives Interesse an abstrakten Datenstrukturen voraus . Es mag unglaublich klingen, aber meiner Erfahrung nach gibt es Programmierer, die überhaupt kein Interesse daran haben und die gelangweilt und überfordert sind von Elementen, die komplexer sind als einfache Arrays. Sie können sich hin und her streiten, ob diese den Job machen sollen, den sie machen, aber es ist, was es ist.

Wenn die Leute nicht daran interessiert sind, werden sie es nicht verstehen. Schlicht und einfach. Ich würde wetten, dass Desinteresse der Hauptgrund für schlechte Noten in der Schule ist, nicht für fehlende Intelligenz.

Das heißt, hier wäre ein Lehrplan, wie ich ihn anwenden würde, basierend auf dem Aufbau von Wissen von unten nach oben. Es hat bei mir nicht funktioniert, aber Sie können es als Inspiration nehmen, Ihre eigenen zu rollen.

GUI

Während der folgende Ansatz nicht unbedingt GUI-Unterstützung für die Aktionen benötigt ( git addin einem Hallo-Welt-Repository ...), hilft es enorm , von Anfang an eine GUI zur Visualisierung des Repositorys zu haben. Wenn Sie sich nicht entscheiden können, welchen Sie verwenden möchten, nehmen Sie gitkals letzten Ausweg. Wenn Sie einen visuellen Editor verwenden, suchen Sie die gitGUI-Komponente.

Die (statische) Datenstruktur ist der Schlüssel

Beginnen Sie mit der Erläuterung der internen Datentypen (es gibt nur drei plus eins: Blobs, Bäume, Commits, mit Anmerkungen versehene Tags, von denen der letzte in dieser Phase keine Rolle spielt) und ihrer Struktur. Sie können dies ganz einfach mit einem Stift auf dem Whiteboard tun. Der Baum ist einfach zu zeichnen, da er niemals geändert werden kann. Sie können buchstäblich immer nur Dinge hinzufügen. Sie können eine Wiedergabesitzung in einem frisch erstellten lokalen Repository durchführen und git cat-filedie tatsächlichen Objekte untersuchen, um ihnen zu zeigen, dass sie tatsächlich so trivial sind wie angekündigt.

Wenn Sie ihnen helfen können, das zu verstehen

• ... gibt es buchstäblich nur drei Arten von Objekten in der Geschichte, die alle sehr einfach, fast trivial und einfach sind
• ... die meisten gitUnterbefehle "massieren" diese Objekte einfach auf die eine oder andere Art und Weise, wobei es sich um nahezu triviale Operationen handelt (im Grunde gibt es nur eine: fügen Sie irgendwo ein neues Commit hinzu), und ...
• ... alles ist sofort zu sehen mit lsund git cat-file...

dann haben sie die mentale Übersetzung dessen, was sich tatsächlich im Repository befindet. An diesem Punkt erinnern sich die Senioren vielleicht daran, dass die Interna von svnarkaner Magie sind (hatten jemals Probleme mit Sperren im SVN-Repository oder mit der "Wiedereingliederung" von Zweigen und dergleichen?), Und dies kann sie nur ein wenig motivieren.

Ein Problem, speziell bei Menschen verwendet svn, ist gewöhnungsbedürftig zu der Idee , dass ein commit (das Objekt, nicht die Handlung) immer ist das ganze Verzeichnisbaum. In svnwerden Personen zum Festschreiben einzelner Dateien verwendet. Es ist ein radikal anderer Ansatz. Oh, und die Tatsache, dass derselbe Begriff "Festschreiben" sowohl für ein statisches Objekt als auch für eine Aktion verwendet wird, hilft auch nicht.

Das andere Problem für svnJungs ist, dass sie svneinen linearen Verlauf verwenden, keinen Baum. Dies ist wiederum völlig anders. Das ist also die Zeit , diese Unterschiede zu zeigen viel .

Aktionen in Bezug auf die Struktur erklärt

Wenn sie verstanden haben, aus welchen Teilen ein gitRepository besteht, ist es an der Zeit, ihnen genau zu zeigen , was die einzelnen gitUnterbefehle in Bezug auf diese tun.

Ich spreche über add, commitin Verbindung mit dem lokalen Arbeitsverzeichnis und der Bühne (stellen Sie sicher, dass sie verstehen, dass das Arbeitsverzeichnis nicht mit dem Staging-Bereich identisch ist, der nicht mit dem Repository identisch ist).

Wenn sie verstanden haben, dass diese Befehle einfach den Baum vergrößern (der zu diesem Zeitpunkt wiederum aus drei Typen besteht - Blobs, Bäume, Festschreibungen, nicht nur Festschreibungen), können Sie eine erste git pushund git pull(im Schnellvorlaufmodus!) ) , um ihnen zu zeigen , dass gitbuchstäblich nur seine Objekte um drängt, dass die Hash - Werte sind wirklich nur Inhalt Hashes, dass man leicht das Zeug um mit einem Dateisystem - Kopierbefehl usw. kopieren.

Halten Sie sich natürlich fern von unnötigen Optionen dieser Befehle, wir sprechen git add hello.txthier.

Geäst

Beachten Sie, dass die Verzweigung für die svnMenschen besonders schwer ist , da sie völlig anders ist. Das svnModell ist viel einfacher zu visualisieren, da es im Grunde nichts zu visualisieren gibt - es ist in einfacher Sicht. Das gitModell nicht so sehr. Vergewissern Sie sich von Anfang an, dass es sich bei Zweigen und Tags lediglich um "Haftnotizen" handelt, die auf eine bestimmte Stelle verweisen, und dass sie im Sinne der statischen, unveränderlichen Historie tatsächlich nicht "existieren".

Machen Sie dann ein Beispiel nach dem anderen, um zu zeigen, was Sie tatsächlich damit machen können. Wie Sie selbst gewohnt zu sein scheinen, sollten gitSie keine Probleme haben, dort Motivation zu finden. Stellen Sie sicher, dass sie dies immer in Bezug auf das Wachstum des Baums sehen.

Wenn sie das unten haben, können Sie erklären, wie git pullwirklich ist git fetch && git merge; Wie alle Repositorys tatsächlich genau die gleichen Objekte enthalten (entspricht git fetchfast dem Kopieren von Inhalten scpinnerhalb des Git-Objektverzeichnisses) und so weiter.

Wahrscheinlich, wenn Sie bis zu diesem Zeitpunkt Ihr Interesse noch nicht geweckt haben, können Sie genauso gut aufgeben, aber wenn sie es schaffen, so weit zu kommen, haben sie alle mentalen Werkzeuge zur Verfügung und es sollte wenig geben Angst mehr beteiligt. Der Rest (Git-Workflow ...) sollte dann bergab sein.

Letzte Worte

Das klingt nach viel Aufwand und ist es auch. Verkaufen Sie das nicht als "Wir brauchen das für dieses Projekt", sondern als "das hilft Ihnen persönlich bei der Entwicklung und hilft Ihnen bei all Ihren weiteren Interaktionen". Dafür braucht man viel Zeit und Zeit ist Geld. Wenn Sie diesbezüglich keine Zustimmung des Managements haben, lohnt es sich möglicherweise nicht. Sie sollten es vielleicht mit Ihrem Chef besprechen.

Wenn Sie beschließen, das Unterrichten der Entwickler aufzugeben, die scheinbar nicht in der Lage sind, es zu gitverstehen , es jedoch in Zukunft unbedingt zu verwenden, sollten Sie in Betracht ziehen, die gesamte Interaktion mit gitBefehlen durch zusammengestellte Skripte oder eine GUI zu ersetzen, die alle gitDetails wegnimmt. Gießen Sie die gesamte Fehlerkontrolle usw. in die Skripte und versuchen Sie, diese zum Laufen zu bringen.

Ich möchte Sie auf diesen Blogeintrag von Joel Spolsky verweisen .

Der Grund, warum diese jungen Entwickler es schnell lernen, ist sehr wahrscheinlich, dass sie keine vorher festgelegte Vorstellung davon haben, wie die Versionskontrolle im Allgemeinen funktioniert, oder zumindest kein so tief verwurzeltes mentales Modell davon. Als solche kommen sie mit einem sauberen Schiefer herein. Ihre erfahreneren Programmierer versuchen wahrscheinlich, die Konzepte anzuwenden, die sie bereits kennen, und scheitern daran.

Darüber hinaus, so sehr ich es nicht gerne sage; wer liest eigentlich bedienungsanleitungen? Normalerweise sind sie sehr schlecht darin, die grundlegende Verwendung zu erklären. Schauen Sie sich einfach die Seite git commit aus dem Handbuch an und überlegen Sie, wie viele neue Begriffe und Ausdrücke jemandem vorgestellt werden, der mit dem Konzept nicht vertraut ist. Ohne eine gute Einführung hätte ich wahrscheinlich sofort aufgegeben, Git zu benutzen.

Mein persönlicher Rat wäre, die Befehle zu erklären:

• git add <files>
• Git Commit
• Git ziehen
• Git Push
• Git Status

Als Nächstes sollten logische Zusammenführungskonflikte erläutert werden, da dies definitiv Ihr erstes Problem sein wird, sobald die Benutzer gelernt haben, wie Code festgeschrieben wird.

In der Regel wird es Situationen geben, in denen die Leute mehr Zeit in Lerninhalte investieren müssen (Zurücksetzen, Markieren, Zusammenführen von Konflikten, Verzweigen, Umbasieren, Verknüpfen), aber der Versuch, all dies zu erklären, bevor es benötigt wird, hilft den Leuten nicht, die Schwierigkeiten haben, hineinzukommen der Fluss.

Um es zusammenzufassen: Aus meiner persönlichen Erfahrung heraus verbringen manche Leute einfach nicht so viel Zeit damit, sich mit neuen Techniken, Konzepten oder Werkzeugen zu befassen, und sie tendieren dazu, Dinge, die Sie ihnen vorstellen, langsamer aufzunehmen. Dies bedeutet nicht, dass sie schlechte Programmierer oder schlechte Leute sind, aber sie haben normalerweise eine engere Kompetenz.

Git ist ein großes Umdenken, wenn Sie gelernt haben, wie man Quellcodeverwaltung auf SVN macht. Viele der Gewohnheiten, die Sie dort entwickelt haben (was für SVN möglicherweise die beste Vorgehensweise war), werden Sie bei der Verwendung von Git irreführen. Dies liegt hauptsächlich daran, dass das Verzweigungsmodell von Git so grundlegend anders ist. Es nutzt nicht Ordner für Filialen, und es ist auch möglich , sie nicht-linear zu machen , weil es entworfen wurde , um die verteilten Anwendungsfälle besser zu unterstützen. Es dauert einige Zeit SVN Gewohnheiten abgewöhnen und verstehen , wie Sie soll git verwenden.

Einfach anfangen

Sie sagen, Sie haben Gitflow als Standard für die Zweigstellenverwaltung ausgewählt. Das erscheint mir als Ihr größter Fehler.

So zitieren Sie Gitflow als schädlich :

Alle diese Zweige, die verwendet werden, erzwingen, dass GitFlow einen ausgeklügelten Satz komplizierter Regeln hat, die beschreiben, wie sie interagieren. Zusammen mit der immateriellen Geschichte erschweren diese Regeln den Entwicklern den täglichen Gebrauch von GitFlow.

Können Sie sich vorstellen, was passiert, wenn Sie ein komplexes Regelwerk wie dieses erstellen? Das ist richtig - Menschen machen Fehler und brechen sie versehentlich. Im Fall von GitFlow geschieht dies die ganze Zeit. Hier ist eine kurze, keineswegs vollständige Liste der häufigsten Fehler, die ich beobachtet habe. Diese werden ständig, manchmal täglich, oftmals immer wieder von denselben Entwicklern wiederholt - die in den meisten Fällen in anderen Softwarebereichen sehr kompetent sind.

Ihre Entwickler sind wahrscheinlich von der Komplexität dieses Standards überwältigt. Ich persönlich denke nicht, dass es irgendeinen Nutzen hat, und der Artikel oben macht das gleiche Argument. Aber das ist eine separate Diskussion. Objektiv gesehen ist es jedoch ein ziemlich starker Standard mit viel manueller Verwaltung, und es erfordert viel kognitiven Aufwand.

Sie müssen einfacher anfangen. Machen Sie sich jetzt keine Gedanken über einen Verzweigungsstandard. Konzentriere dich darauf, dass sie sich zuerst an Git gewöhnen . Sie brauchen nur ein paar Operationen, um loszulegen:

• Klon
• ziehen
• Ast
• verschmelzen
• verpflichten
• drücken
• Wissen darüber, wie es .gitignorefunktioniert
• vielleicht tag

Ja, Ihre Geschichte könnte zuerst etwas chaotisch aussehen. Das ist okay. Mach dir jetzt keine Sorgen. Hol sie dir einfach mit git .

Allmählich das Wissen erweitern

Von hier aus können Sie sie schrittweise in etwas weiter fortgeschrittener Verwendung erziehen.

• Bringe ihnen das epische Versteck-Kommando bei
• Bringen Sie ihnen bei, wie Sie das Zurücksetzen verwenden, wenn Sie das gerade getätigte lokale Commit verwerfen möchten
• Bringen Sie ihnen bei, wie man etwas ändert
• Bringen Sie ihnen bei, wie man einen Rebase ausführt, um unnötige Merge-Commits zu vermeiden
• Bringen Sie ihnen bei, wie sie interaktiv einen Rebase durchführen, um ihre Commits vor dem Push zu organisieren
• Bringen Sie ihnen bei, wie sie von jedem Hash, Tag oder Zweig auschecken können

Achten Sie besonders darauf, dass Sie die Gelegenheit nutzen, ihnen klarere Wege zu zeigen, wie sie ihren Code in das Repository aufnehmen können, und lernen Sie diese Dinge auch in Schulungsaktivitäten und was Sie haben. Ein oder zwei Guru zu haben, denen sich die Leute nähern können, wenn sie nicht sicher sind, was sie tun sollen, wird ebenfalls viel helfen. Wenn Sie so etwas wie Slack haben, erstellen Sie einen eigenen Kanal und ermutigen Sie die Leute, dort Fragen zu stellen und zu beantworten.

Dann wählen Sie eine Verzweigung Standard

Sobald Sie die meisten der Unternehmen zuständig sind mit git überhaupt haben, dann können Sie sich verzweigenden Standards suchen. Aus mehreren Gründen ist es eine wirklich schlechte Idee, sich für eine zu entscheiden:

• Sie verfügen nicht über ausreichende Kenntnisse des Tools, um festzustellen, ob der Standard für die Anwendungsfälle des Unternehmens geeignet ist
• Sie werden keine alternativen Standards anbieten können
• Sie müssen sowohl das Werkzeug als auch den Standard gleichzeitig lernen
• Einige gehen davon aus, dass der von Ihnen gewählte Standard die einzige Möglichkeit ist, Git zu verwenden
• Sie sind nicht in der Lage, seltene Randfälle zu identifizieren, bei denen der Standard mehr schadet als nützt

Sie sollten keinen Git-Workflow vom Berg aus weitergeben. Ihr Team muss Informationen dazu haben und Ihnen Feedback geben können, ob es gut läuft oder nicht. Sie können dies nicht tun, wenn sie die Grundlagen noch nicht einmal verstehen. Sie brauchen nicht jeden einzelnen Entwickler, um über solch tiefes Wissen zu verfügen, aber Sie brauchen definitiv mehrere, die es wirklich verstehen . Und man braucht die überwiegende Mehrheit, um zumindest in Sachen Git kompetent zu sein, damit sie genug wissen, um ein wenig auf den Schienen zu bleiben.

Hier sind einige Alternativen zu Gitflow, die Ihr Team in Betracht ziehen kann:

• OneFlow
• Workflow für Funktionszweige
• Zentraler Workflow

Schauen Sie sie und Gitflow an, wägen Sie sie gegen Ihre Anwendungsfälle ab und wählen Sie einen passenden aus.

Ich fand Stackoverflow sehr hilfreich, als ich zum ersten Mal die Git-Terminologie aufnahm. Fragen wie diese waren wirklich nützlich für mich (hauptsächlich wegen ihrer Prägnanz) und ich hielt sie in den ersten Wochen, in denen ich sie verwendete, in Registerkarten offen. Vielleicht ein paar Antworten fett ausdrucken? Besonders das Diagramm auf dem ersten.

Was sind die Unterschiede zwischen "git commit" und "git push"?

Was ist der Unterschied zwischen "Git Pull" und "Git Fetch"?

Ich fand auch eine visuelle Darstellung des Kofferraums erstaunlich nützlich, aber Sie decken diesen bereits mit SourceTree ab.

_{Abgesehen davon gehört dieses Bit wahrscheinlich in einen Kommentar, aber mir fehlt der Repräsentant: Ich bin einer der in der Frage erwähnten Juniorberater. Bevor ich anfing, hatte ich eine Vorstellung davon, was ein Quellcodeverwaltungssystem ist, und ich habe SVN buchstäblich zweimal angestupst. Gusdor gibt mir mehr Anerkennung, als ich verdiene. Das gesamte Team hatte hochqualifiziertes Git-Training, Spielzeug und Zeit zum Spielen. Das Problem liegt nicht in Gusdors Anweisungen. Ich hoffe, es gibt eine gute alternative Lösung, damit ich es hart bookmarken und mehr lernen kann.}

Kauf ihnen ein Buch

Ehrlich gesagt bin ich direkt in das Lager gefallen, das Sie beschreiben. Ich stamme aus SourceSafe und ClearCase. Anfangs war Git für mich völlig unergründlich, obwohl mein Chef es mehrmals durchging.

Was mir geholfen hat, war ein Buch, in dem klar beschrieben wurde, was vor sich ging, aber was noch wichtiger ist, wie sich Git grundlegend von allen Quellcodeverwaltungssystemen unterschied, die ich zuvor verwendet hatte. Jetzt ziehe ich Git jeder anderen Wahl vor.

Leider kann ich mich nicht erinnern, welches Buch ich zu der Zeit gelesen habe, aber stellen Sie sicher, dass sich das, was Sie für sie bekommen (oder darauf hinweisen) darauf konzentriert, wie es anders ist und wie es eine andere Denkweise erfordert.

Die beste Vermutung für eine Buchempfehlung ist:

Pro Git von Scott Chacon (Amazon-Link, um den Kauf zu vereinfachen: https://www.amazon.com/dp/1484200772/ref=cm_sw_r_cp_dp_T1_BNruzbBQ8G9A6 )

Hinweis : Kaufen Sie kein Nachschlagewerk für Git. Das wird überhaupt nicht helfen.

Meiner Erfahrung nach können manche Leute Git gut gebrauchen, ohne es zu verstehen. Sie finden ein grundlegendes Tutorial, lernen grundlegende Befehle kennen und können loslegen. Das ist wahrscheinlich, wo Sie Junior-Berater es passen. Ich glaube nicht, dass Sie in wenigen Tagen wirklich Git lernen können!

Andere Leute können das nicht, sie müssen verstehen, was git tut, und das braucht mehr Zeit. Ich war in dieser Kategorie; Ich fand es sehr hilfreich, mit den Inhalten des .gitVerzeichnisses zu spielen. Dann begannen die Dinge für mich zu klicken. Auch Eins-zu-Eins-Sessions mit unserem Tech-Lead haben geholfen.

Sie können Eins-zu-Eins-Tutorials durchführen, weil die Leute unterschiedlich lernen und sich über verschiedene Teile sehr verwirrt fühlen. In einer Eins-zu-Eins-Sitzung ist es einfacher, sie zu sehen und zu lösen. Wenn es sie wirklich stört, dass sie nicht verstehen, wie git Zweige verfolgt, zeigen Sie ihnen den Inhalt des .gitVerzeichnisses und so weiter ...

Ich spiele damit, mich vorzustellen, gitwo ich bin (von TFS), also ist Ihre Frage für mich zum richtigen Zeitpunkt , zumal ich auch etwas zurückgedrängt wurde, als ich das Thema angesprochen habe.

In Peopleware lauten die zugrunde liegenden Thesen des gesamten Buches:

Die Hauptprobleme unserer Arbeit sind weniger technologischer als vielmehr soziologischer Natur .

Ich spreche das an, weil unser Problem kein technisches ist. gitObwohl ein wenig stumpf, geht es wahrscheinlich nicht über die Fähigkeiten von Ihnen oder meinen älteren Entwicklern hinaus, es sei denn, sie sind extrem dumm *.

Lassen Sie es uns aus der Sicht Ihrer Entwickler betrachten, als Menschen, nicht als technische Maschinen:

Sie fordern sie auf, kein Versionsverwaltungssystem mehr zu verwenden, das sie (wahrscheinlich) beherrschen, und keines, das sie nicht beherrschen. Es ist ein bisschen so, als würde man einen gitExperten bitten , nicht mehr zu verwenden gitund sich zu bewegen, svnoder? Ich denke, die Git-Expertin würde sich darüber ärgern und wahrscheinlich nicht viel Mühe geben, svnweil es gut gitfunktioniert und es gibt Teile, die sie wirklich mag, die wirklich schwer zu machen sind svn.

Das ist wahrscheinlich der Grund, warum die Junioren es besser aufgenommen haben - vielleicht haben sie nicht den Dreh raus svnund githaben die Chance, es fallen zu lassen.

Die Senioren achten jedoch auf die Opportunitätskosten - wenn sie lernen git, dann sind sie nicht:

• Lernen Reagieren / Schräg / Swift / Blockchain / Kotlin (einige andere , was sie fühlen , sie sollten das Lernen sein).
• Doing DIY / whittling / segeln / Poesie / Glockenspiel / was auch immer sie eigentlich wollen .
• Zeit mit ihren Kindern / Verwandten / Freunden / Lebensgefährten verbringen.

• Bereitstellung dieser "großen neuen Sache" - es gibt eine Frist, ein Budget usw. Sie sind wahrscheinlich besorgt darüber.

  "Ich muss all das tun, warum muss ich es verwenden, git wenn wir bereits über die Quellcodeverwaltung verfügen?"

Welche Gründe haben Sie ihnen gegeben, um von einer Sache, in der sie gut sind, zu einer anderen zu wechseln, die offen gesagt umständlich ist, wenn Sie neu darin sind, und ein vollständiges Umdenken in Bezug auf Ihre Arbeitsweise erfordert? Haben Sie die Vorteile der gitFunktionen erläutert ?

Pull-Anfragen? Feinkörnige Checkins? Verteilte Quelle? Gabeln?

Haben sie in diese Gründe gebracht? Dies sind massive strukturelle Veränderungen, wenn Sie sich in einer zentralen Denkweise der Quellcodeverwaltung befinden - nicht nur technische, sondern auch kulturelle. Wir wissen, wie schwierig es ist, eine Kultur zu verändern.

Überlegen Sie sich also im Grunde, wozu Sie Ihre Entwickler auffordern, und stellen Sie sicher, dass es die richtigen Gründe dafür gibt. Wenn du es einfach machen willst, weil svnes dumm und alt ist und niemand es mehr benutzt, ist es in Ordnung, aber es ist schwieriger, es an andere zu verkaufen, die nicht so denken wie du und einfach nur mit ihrem Tag weitermachen wollen. Sie müssen die Vorteile in Begriffen angeben, die für Ihr Team und für das Projekt sinnvoll sind. Wenn Sie sie dazu bringen können, sich einig zu werden, dass gitsich das lohnt, müssen Sie sich keine Sorgen machen, dass sie die Technologie erlernen, sondern nur dem Workflow zustimmen, den Sie eingerichtet haben.

Viel Glück.

Ich denke, dies ist weniger eine Frage der Softwareentwicklung als vielmehr eine psychologische Frage. Ich möchte darauf verweisen Algorithms to Live By: The Computer Science of Humand Decisions. Darin geht der Autor auf das Thema des Explore / Exploit-Kompromisses ein. Menschen durchlaufen normalerweise eine Phase der Erforschung und dann eine Phase der Ausbeutung (Nutzung) dessen, was sie erforscht haben. Es steckt eine solide mathematische Theorie dahinter, warum dies der Fall ist, um in einem bestimmten Intervall eine optimale Nutzung von etwas zu erzielen.

Dies gilt auch für Alter und Erfahrung. Der Mensch sieht sein eigenes Leben als eine Pause, und nach einer bestimmten Erkundungsphase ist es optimal, sein Wissen zu nutzen. Sie zitierten eine Studie, in der ältere Teilnehmer gefragt wurden, ob sie jemanden kennenlernen möchten, den sie mögen oder eher ein Familienmitglied. Normalerweise wählten sie das Familienmitglied, während jüngere Leute mit größerer Wahrscheinlichkeit die berühmte Person wählten. Als sie gefragt wurden, wie sie sich entscheiden würden, ob sie 20 Jahre jünger wären, wählten die älteren Menschen routinemäßig auch die berühmte Person. Das deutet darauf hin, dass Menschen aufhören, ihre sozialen Netzwerke aufzubauen, wenn sie glauben, dass sie weniger vom Erkunden als vom Ausnutzen des Wissens haben.

Ihre leitenden Ingenieure sind wahrscheinlich älter, sie haben wahrscheinlich einige Versionskontrollsysteme durchlaufen. SVNist wahrscheinlich die beste, die sie bisher verwendet haben (zumindest in Bezug auf die älteren Versionssysteme, die ich verwendet habe, hat SVN sie alle geschlagen).

Ihre optimale Strategie besteht darin, SVN auszunutzen, da sie ihre Erkundungen durchgeführt haben und festgestellt haben, dass dies die beste ist, die sie jetzt ausnutzen.

Dies ist die grundlegende menschliche Psychologie und hunderttausende Jahre evolutionärer Optimierung, gegen die Sie kämpfen.

Sie müssen ihnen zeigen, a) wie lange sie noch eine Karriere vor sich haben, um sie darauf vorzubereiten, das Intervall, in dem sie sich selbst sehen, aus einer anderen Perspektive zu betrachten, und b) sie fragen, was sie für großartig halten und was sie fehlt in SVN. Sie können Hunderte von Vorteilen auslegen git, aber sie werden bereits eine klare Vorstellung davon haben, warum SVNdas Beste ist, nachdem sie wahrscheinlich 5 Versionskontrollsysteme zuvor erlebt haben. Sie müssen den Spalt in der Rüstung dieses Arguments finden und dann sehen, ob Sie gitdiese Probleme lösen können, dann haben sie sich selbst überzeugt.

Gib ihnen kein Werkzeug oder eine GUI, um Git zu benutzen. Es wird nur die Dinge verwirren. Git wurde so konzipiert, dass es auf einer Befehlszeile ausgeführt wird, damit es wahrscheinlich der Ort ist, an dem es gelernt wird. Jede GUI hat möglicherweise ihre eigenen Begriffe und Besonderheiten. Halten Sie sich an das, was einfach ist.

Als nächstes sollten Sie sich einige der Probleme ansehen, die Git besser als SVN macht. Um Ihr Team dazu zu bringen, es zu lernen, müssen Sie es motivieren, zu sehen, warum git besser ist.

• Commit-Fähigkeit, wenn keine Verbindung zum Netzwerk besteht
• Fähigkeit, eigene Zweige zu erschaffen und damit zu spielen
• Patches, die untereinander gesendet werden können und trotzdem Titel zusammenführen
• Kirschernte ohne Schmerzen.
• Änderungen umbasieren
• Finden von Fehlern mit Git Splice

Ich bin sicher, SVN ist in den letzten Jahren weitergegangen, aber das waren Dinge, die eine Welt der Schmerzen verursachten. Wenn die Entwickler erkennen, dass dieses neue Tool nicht nur ein schickes Ding ist, sondern solide Vorteile für ihre Arbeit hat, werden sie wahrscheinlich eher dahinter stehen.

Es ist eine neue Sache zu lernen und es gibt genug Ähnlichkeiten, die verwirrend werden können, aber im Jahr 2017 ist DCVS wirklich eine essentielle Fähigkeit für jeden Entwickler.

Sagen Sie ihnen, sie sollen sich keine Sorgen machen

In Git ist es fast unmöglich zu verlieren, wenn die Arbeit einmal feststeht. Die einzige Arbeit, die Sie leicht verlieren können, ist Arbeit, die noch nicht zugesagt wurde.

Zeigen Sie ihnen, wie es git reflogfunktioniert. Sie müssen nicht wissen, wie man es benutzt; sie müssen nur wissen, dass es da ist, damit sie Hilfe bekommen, um ihre Arbeit zurückzubekommen, wenn etwas schief geht.

Dann beeindrucken Sie sie mit dieser einfachen Regel: Wenn Sie Zweifel haben, verpflichten Sie sich. Sie können das Commit später jederzeit zurücksetzen (sogar von der Fernbedienung aus!).

Verwenden Sie keine GUI

Eine GUI wird ihnen einen schnelleren Einstieg ermöglichen, aber sie werden Git nie wirklich verstehen. Darüber hinaus habe ich festgestellt, dass es nicht "fast unmöglich ist, engagierte Arbeit zu verlieren", wenn Sie eine Git-GUI verwenden. Ich habe GUIs gesehen, die schreckliche Dinge getan haben, wie eine Checkliste beim Zusammenführen zu präsentieren und dann, wenn der Benutzer ein Element deaktiviert, diese Datei ohne Warnung und ohne Aufzeichnung aus dem Verlauf zu löschen. Eine GUI ist weitaus schlechter als das Erlernen von Git über die Befehlszeile.

Paarprogrammcode wird festgeschrieben

Das Lernen, git add -Agefolgt von, git commitsollte nicht zu schwierig sein, aber besonders beim Zusammenführen (oder erneuten Basieren) mit der Fernbedienung benötigen sie Unterstützung. Machen Sie deutlich, dass jeder jederzeit um Hilfe bitten kann. Halten Sie sich bereit, während Sie die Befehle eingeben und sich Notizen machen. Mit der Zeit werden sie die Anzahl der Situationen, die sie ohne Hilfe bewältigen können, schrittweise erhöhen.

Git ist schon sicher

Jemand über sprach davon, "einen sicheren Ort zum Spielen zu haben". Aber Git ist dieser sichere Ort. Es gibt nur zwei normale alltägliche Fälle, in denen es leicht ist, Arbeit zu verlieren:

• Nicht festgeschriebener Code
• Verwenden einer GUI

Stellen Sie sicher, dass sie früh und häufig Commits durchführen und mit einer GUI nicht den falschen Weg einschlagen. Sie werden bald feststellen, dass sie Git ihren Code noch mehr anvertrauen können als anderen Versionsverwaltungssystemen in der Vergangenheit.

Ich würde einen Blick auf Gitless raten . Es ist ein Wrapper-Over-Git, der den grundlegenden Workflow erheblich vereinfacht (Sie müssen sich keine Gedanken über einen Staging-Bereich machen, die Zweige behalten ihre eigenen Arbeitskopien von Dateien, die einfacheren Verwendungen git rebasewerden behandelt gl fuseusw.), während ein zugrunde liegendes Git-Repository für die Zusammenarbeit beibehalten wird oder wenn Sie etwas Ungewöhnliches tun müssen. Außerdem sind die Nachrichten ein bisschen unerfahrener. Und die Befehle sind nah genug, um als Sprungbrett zu fungieren, wenn sie ein System verwenden müssen, ohne aus irgendeinem Grund gitlos darauf zu sein.

Ich habe versucht, die Grundlagen der Verwendung der Befehlszeile von git zu dokumentieren. Es war immer noch verwirrend - sowohl für mich selbst (der Erfahrung mit Perforce und Source Safe hatte) als auch für Programmierer, die das alte Paradigma "Einfach die relevanten Ordner komprimieren" vorzogen. Es war besorgniserregend, dass ein undurchsichtiges Tool den Inhalt meines Arbeitsverzeichnisses änderte und sich häufig mit dem Tool streiten musste, um bestimmte Änderungen in mein Arbeitsverzeichnis aufzunehmen.

Stattdessen verwende ich zwei Arten der Indirektion.

• Ich verwende GitKraken, um einen visuellen Verlauf meiner Zweige und eine GUI bereitzustellen, die die Befehlszeilenanweisungen verbirgt. GitKraken kümmert sich um die Interaktionen zwischen dem Remote-Repository "origin" und meinem lokalen Arbeitsverzeichnis.

• Ich behalte auch ein "echtes" lokales Arbeitsverzeichnis, das sich von dem unterscheidet, was git für mein lokales Arbeitsverzeichnis hält. Ich synchronisiere diese beiden Arbeitsverzeichnisse manuell, wodurch ich mich viel wohler fühle, als wenn ich beabsichtige, Änderungen in meinem Arbeitsverzeichnis vorzunehmen.

Kann ich diesen Mitarbeitern helfen, Git zu lernen?

Sind Sie sicher, dass das Problem Git und nicht etwas anderes ist? Aus dem Kommentar geht hervor, dass das Management beschlossen hat, etwas zu ändern, ohne sich von den erfahrenen Mitarbeitern zu beteiligen, und jemanden beauftragt, der jünger als sie ist, die Änderung voranzutreiben. Das scheint ein guter Ausgangspunkt für ein Scheitern zu sein. Git Komplexität ist kein Problem, das Problem ist, dass ihnen eine Änderung aufgezwungen wird, die sie nicht für nötig halten.

Konzentriere dich also nicht darauf, wie du ihnen Git beibringst, solange sie keinen Vorteil für den Schalter sehen, den sie haben werden. Zeigen Sie ihnen, wie Git eine Lösung für Probleme ist, die sie jetzt haben. Nicht, wie Git ihnen Dinge liefern kann, die sie noch nicht benötigen, nicht, wie Git eine Lösung für Probleme anderer Leute bietet, wie Git Probleme löst, mit denen sie gerade kämpfen. Dann ist es kein Problem, ihnen Git beizubringen.

Oft wird Git in einem Unternehmen eingesetzt, um Probleme mit Filialen zu lösen. Ja, es ist besser in Zweigen als in Subversion, aber es macht keine Magie.

Es ist sehr wahrscheinlich, dass die erfahrenen Entwickler in vielen Unternehmen gearbeitet haben, die dies getan haben.

• Als Geschäftsleitung geschaffene Filialen sind nicht bereit, sich zwischen widersprüchlichen Anforderungen zu entscheiden
• Habe für jeden Kunden eine Filiale benutzt anstatt Konfigurationsschalter.
• Wir mussten für jeden Kunden einen Bugfix-Zweig einrichten, da das Management nicht gewillt war, alle Kunden auf dieselbe Version der Software zu aktualisieren
• Usw.

Deshalb sagt mir mein Verstand, sobald mir jemand sagt, dass ein Werkzeug gut zum Verzweigen ist.

Das Management möchte nicht entscheiden, in welche Richtung sich das Unternehmen entwickelt, und es wäre mir lieber, wenn mein Leben meine Arbeit in 101 verschiedenen Branchen zusammenführen und 101 verschiedene Versionen der Software testen müsste.

Auch das Konzept, dass zwei Personen gleichzeitig an derselben Datei arbeiten, ist „gut“ und für jemanden, der ein gut laufendes Projekt erlebt hat, einfach nicht akzeptabel. Daher ist es unwahrscheinlich, dass Git als Tool dafür beworben wird Entwickler mögen dich.

Jedes Mal, wenn ich mir die Geschichte in Git anschaue, ist es sehr schwer zu erkennen, warum Code geändert wurde, da 50% oder mehr der Geschichte Zusammenführungen sind, die logischerweise niemals öffentlich gewesen sein sollten und bedeutungslos werden, sobald der Code die Entwickler verlässt Maschine.

Aber ich würde gerne irgendwo arbeiten, wo:

• Kein Code gelangt in das zentrale System, bis er kompiliert und auf einem Trust-Server Unit-getestet wurde.
• Es gibt eine einfache Möglichkeit, Codeüberprüfungen zu verfolgen
• Wo immer ich ein "get" mache, kompiliert und funktioniert der Code immer
• Wo ich meine Änderungen vornehmen kann, ohne ein Rennen mit jemand anderem zu haben oder im Büro herumlaufen zu müssen, um zu sehen, ob ich den Build gebrochen habe.

Löse also die wirklichen Probleme und wenn Git Teil der Lösungen ist, werden sich deine erfahrenen Entwickler einkaufen, aber erwarte nicht, dass sie Git mögen, nur weil es ein cooles Spielzeug ist, das „magische Verschmelzungen“ machen kann.

Daher sollte überall dort, wo ein Entwickler von seinem lokalen Git auf den zentralen Git pushen kann, ein kontrollierter automatisierter Prozess die Änderungen von den Entwicklern übernehmen und sie nach dem Testen usw. überprüfen und prüfen, ob Fusionen in Ordnung sind, um den zentralen Git zu aktualisieren Zweige usw., die nicht von langfristigem Interesse sind.

Ich gehe davon aus, dass Kiln ( http://www.fogcreek.com/fogbugz/devhub ) oder sogar GitHub mit einem "Pull Request" -Workflow erfahrene Entwickler bei Laune halten würden. Beginnen Sie also nicht mit dem niedrigen Level, sondern mit dem verbesserten Prozess.