it-swarm.com.de

Was kann ich für Entwickler tun, die Git nicht lernen können?

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. Ich bekomme die gleichen trivialen Fragen gestellt, obwohl ich Benutzerhandbücher, Schulungsaktivitäten und Whiteboard-Sitzungen bereitgestellt habe. Wir hatten zwei Junior-Berater, die in wenigen Tagen alles aufgegriffen haben, und das hat das Problem wirklich beleuchtet. Dies ist kein Muster, das auf Git beschränkt ist, aber dadurch sichtbar geworden ist.

Frage

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

Kann ich diesen Mitarbeitern helfen, Git zu lernen?

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

68
Gusdor

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 versuchte, 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 fand ich endlich heraus, was ich brauchte, um daran vorbei zu kommen:

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, selbst wenn es unterbrochen wurde und immer noch in einen guten Zustand zurückkehrte. Es dauerte nicht lange, bis Leute zu mir kamen, um mir bei git zu helfen. Alles nur, weil ich mir die Zeit genommen habe, mit einem Spielzeug zu spielen.

Wenn Sie sie nur in die Tiefe werfen, haben Sie Glück, wenn sie es schaffen zu schweben.

150
candied_orange

Der durchschnittliche Entwickler braucht nicht viele gute Sachen. Es ist ein verteiltes Versionsverwaltungssystem, aber die meisten Teams verwenden es mit einem zentralen kanonischen Repo zum Push and Pull.

Die wichtigsten Befehle, die Ihr Team benötigt, sind:

  • änderungen von Remote abrufen und zusammenführen und daraus resultierende Konflikte behandeln (möglicherweise neu basiert)
  • commit und Push Commits an Remote (oder Push an Staging Repo/Branch, 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 verarbeiten
  • 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 (neue Dateien hinzufügen, gelöschte Dateien aus dem Repo entfernen usw.)

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

Dies ist im Sinne von dem xkcd-Comic . Merken Sie sich einfach die Befehle und hoffen Sie, dass die Dinge nicht zu sehr durcheinander geraten, wenn sie einen Fachmann fragen.

32
ratchet freak

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 in der Lage waren, leicht zu meistern komplexe Aufgaben in Git dank SourceTree.

Diese Antwort versucht herauszufinden, wie man ältere Programmierer für git interessiert, und nicht, wie man git am schnellsten lernt - dafür das ausgezeichnete Git Book ist großartig, oder eine beliebige Anzahl von Tutorials (=> Google). Gute Links zu dieser Antwort sind Git ist eine rein funktionale Datenstruktur oder besonders die kurze Wie Git Ihre Daten speichert .

Ich fürchte, ich habe eine ziemlich düstere Sicht darauf. Ich war genau in Ihren Schuhen - ich bin ein git Nerd und wollte ein Team von svn abbringen, mit, seien wir ehrlich, winzigen Ergebnissen. In meinem Fall hat es dazu geführt, dass ich meine eigene Wahrnehmung aktiv verä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 eine ziemlich sanfte Weise gezeigt, was ich tue und was ich in meinem Berufsleben nicht tun möchte.

Es gibt Leute, die anfangen, motiviert zu werden, wenn es um neue Dinge geht, und es gibt Leute, die demotiviert sind. Dies hat nichts mit git zu tun, aber für git haben Sie immer den Effekt "Warum sollten wir es überhaupt verwenden, wenn svn in Ordnung ist?", Was ist eine massive psychologische Barriere.

Außerdem erfordert ein wirklich grokking git ein intensives Interesse an abstrakten Datenstrukturen. Es mag unglaublich klingen, aber meiner Erfahrung nach gibt es Programmierer, die überhaupt kein Interesse daran haben und die von Elementen gelangweilt und überfordert sind, die komplexer sind als einfache Arrays. Sie können 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 Schulnoten ist und nicht die 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 add In einem Hallo-Welt-Repository ...), hilft es enorm , eine GUI für zu haben Visualisierung des Repositorys von Anfang an. Wenn Sie sich nicht entscheiden können, welche Sie verwenden möchten, nehmen Sie gitk als letzten Ausweg. Wenn Ihre Jungs einen visuellen Editor verwenden, suchen Sie ihre git GUI-Komponente.

Die (statische) Datenstruktur ist der Schlüssel

Erläutern Sie zunächst die internen Datentypen (es gibt nur drei plus eins: Blobs, Bäume, Commits, mit Anmerkungen versehene Tags, von denen das letzte zu diesem Zeitpunkt überhaupt keine Rolle spielt) und ihre Struktur. Sie können dies leicht auf einem Whiteboard/mit einem Bleistift 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 Spielsitzung in einem frisch erstellten lokalen Repository durchführen und mit git cat-file Die tatsächlichen Objekte untersuchen, um ihnen zu zeigen, dass sie tatsächlich so trivial wie angekündigt sind .

Wenn Sie ihnen helfen können, das zu verstehen

  • ... es gibt buchstäblich nur 3 Arten von Objekten in der Geschichte, alle sehr einfach, fast trivial und
  • ... die meisten git-Unterbefehle "massieren" diese Objekte nur auf die eine oder andere Weise mit nahezu trivialen Operationen (im Grunde gibt es nur eine: irgendwo ein neues Commit hinzufügen) und ...
  • ... alles ist leicht zu sehen direkt vor Ihnen mit ls und git cat-file ...

dann haben sie die mentale Übersetzung dessen, was sich tatsächlich im Repository befindet. An diesem Punkt können sich die Seniours daran erinnern, dass die Interna von svn arkane Magie sind (hatten jemals Probleme mit Sperren im svn-Repository oder mit "reintegrierenden" Zweigen und so?), und dies kann sie nur ein bisschen motivieren.

Ein Problem, insbesondere bei Leuten, die an svn gewöhnt sind, besteht darin, sich an die Idee zu gewöhnen, dass ein Commit (das Objekt, nicht die Aktion) immer das gesamte Verzeichnis ist Baum. In svn werden Personen verwendet, um einzelne Dateien festzuschreiben. Es ist ein radikal anderer Ansatz. Oh, und die Tatsache, dass der gleiche Begriff "Festschreiben" sowohl für ein statisches Objekt als auch für eine Aktion verwendet wird, hilft auch nicht.

Das andere Problem für svn Jungs ist, dass svn einen linearen Verlauf verwendet, keinen Baum. Dies ist wiederum völlig anders. Dies ist also die Zeit, um auf diese Unterschiede viel hinzuweisen .

Aktionen erklärt in Bezug auf die Struktur

Wenn sie verstanden haben, aus welchen Teilen ein git Repository besteht, ist es Zeit, ihnen genau zu zeigen, was die einzelnen git Unterbefehle tun Bedingungen von denen.

Ich spreche von add, commit in 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 identisch ist als Repository).

Wenn sie verstanden haben, dass diese Befehle einfach den Baum wachsen lassen (der wiederum zu diesem Zeitpunkt aus 3 der Typen besteht - Blobs, Bäume, Commits, nicht nur Commits), Sie können zuerst git Push und git pull (im Schnellvorlaufmodus!) ausführen, um ihnen zu zeigen, dass git buchstäblich nur seine Objekte herumschiebt, dass die Hashes wirklich nur Content-Hashes, die Sie einfach mit einem Dateisystem-Kopierbefehl usw. kopieren können.

Halten Sie sich natürlich von nicht wesentlichen Optionen dieser Befehle fern. Wir sprechen hier von git add hello.txt.

Geäst

Beachten Sie, dass die Verzweigung für svn Personen besonders schwierig ist, da sie völlig anders ist. Das svn Modell ist viel einfacher zu visualisieren, da im Grunde nichts zu visualisieren ist - es ist in der Übersicht. Das git Modell nicht so sehr. Stellen Sie sicher, dass sie von Anfang an wissen, dass Zweige und Tags nur "Haftnotizen" sind, die auf etwas zeigen, und in Bezug auf die statische, unveränderliche Historie nicht "existieren".

Machen Sie dann ein Beispiel nach dem anderen, um zu zeigen, was Sie tatsächlich mit ihnen machen können. Da Sie selbst an git gewöhnt zu sein scheinen, sollten Sie dort keine Probleme haben, Motivation zu finden. Stellen Sie sicher, dass sie dies immer im Hinblick darauf sehen, wie der Baum wächst.

Wenn sie das nicht haben, können Sie erklären, wie git pull Wirklich git fetch && git merge Ist; Wie alle Repositorys tatsächlich genau die gleichen Objekte enthalten (git fetch ist fast dasselbe wie das Kopieren von Sachen mit scp innerhalb des Git-Objektverzeichnisses) und bald.

Wenn Sie zu diesem Zeitpunkt noch nicht durchgekommen sind, um ihr Interesse zu wecken, können Sie wahrscheinlich 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 dies nicht als "wir brauchen das für dieses Projekt", sondern als "dies hilft Ihnen persönlich bei der Entwicklung und hilft Ihnen bei all Ihren weiteren Interaktionen". Sie brauchen dafür eine Menge Zeit, und Zeit ist Geld. Wenn Sie diesbezüglich keine Akzeptanz beim Management haben, lohnt es sich möglicherweise nicht. Sie sollten es vielleicht mit Ihrem Chef besprechen.

Wenn Sie sich entschließen, das Unterrichten der Entwickler aufzugeben, die es anscheinend nicht verstehen können, aber in Zukunft unbedingt git verwenden müssen, sollten Sie in Betracht ziehen, alle Interaktionen mit git-Befehlen durch gekocht zu ersetzen. up-Skripte oder eine GUI, die alle git -Daten entfernt. Gießen Sie die gesamte Fehlerkontrolle usw. in die Skripte und versuchen Sie, dies zum Laufen zu bringen.

25
AnoE

Ich möchte Sie darauf verweisen Blogeintrag von Joel Spolsky .

Der Grund, warum Sie sehen, dass diese Nachwuchsentwickler es schnell aufgreifen, ist sehr wahrscheinlich, weil 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 einer sauberen Tafel 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 Benutzerhandbücher? Normalerweise erklären sie die grundlegende Verwendung nur sehr schlecht. Schauen Sie sich einfach die Git-Commit-Seite 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 es wahrscheinlich aufgegeben, Git genau dort und dann zu verwenden.

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

  • git <Dateien> hinzufügen
  • git Commit
  • git Pull
  • git Push
  • git-Status

Das logische Zusammenführen von Konflikten sollte als nächstes erklärt werden, da dies definitiv Ihr erstes Problem sein wird, sobald die Leute lernen, wie man Code festschreibt.

In der Regel treten Situationen auf, in denen die Benutzer mehr Zeit in das Lernen investieren müssen (Zurücksetzen, Markieren, Zusammenführen von Konflikten, Verzweigungen, Neugründen, Hooks). Der Versuch, all dies zu erklären, bevor es benötigt wird, hilft den Menschen, die Schwierigkeiten haben, sich darauf einzulassen der Fluss.

Um es zusammenzufassen: Aus meiner persönlichen Erfahrung verbringen manche Leute einfach nicht so viel Zeit damit, neue Techniken, Konzepte oder Werkzeuge zu erforschen, und sie neigen dazu, Dinge, die Sie ihnen vorstellen, langsamer aufzugreifen. Dies bedeutet nicht, dass sie schlechte Programmierer oder schlechte Leute sind, aber sie haben normalerweise engere Fähigkeiten.

14
Robzor

Ich fand Stackoverflow sehr hilfreich, als ich zum ersten Mal die Git-Terminologie aufnahm. Fragen wie diese waren für mich sehr nützlich (hauptsächlich wegen ihrer Prägnanz) und ich habe sie in den ersten Wochen, in denen ich sie verwendet habe, in Registerkarten offen gehalten. Vielleicht ein paar Antworten fett gedruckt? 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 diese 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 genannten Juniorberater. Bevor ich anfing, hatte ich eine Idee, was ein Versionsverwaltungssystem ist, und ich hatte SVN buchstäblich zweimal angestupst. Gusdor gibt mir mehr Anerkennung, als ich verdient habe. Das gesamte Team hatte hochqualifiziertes Git-Spezialtraining, Spielzeug und Zeit zum Spielen. Das Problem liegt nicht in Gusdors Anweisung. Ich hoffe, es gibt eine gute alternative Lösung dafür, damit ich es schwer bookmarken und mehr lernen kann.

11
SBaker

Git ist ein Umdenken, wenn Sie gelernt haben, wie man die Quellcodeverwaltung auf SVN durchführt. 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 Ordner nicht für Zweige, und es ist auch möglich, es nichtlinear zu machen, da es entwickelt wurde, um die verteilten Anwendungsfälle besser zu unterstützen. Es dauert einige Zeit, um SVN-Gewohnheiten zu verlernen und zu verstehen, wie Sie angenommen Git verwenden.

Fangen Sie einfach an

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

Um zu zitieren Gitflow als schädlich angesehen :

Alle diese Zweige, die verwendet werden, zwingen GitFlow zu einem ausgeklügelten Satz komplizierter Regeln, die beschreiben, wie sie interagieren. Diese Regeln, zusammen mit der immateriellen Geschichte, erschweren Entwicklern den täglichen Gebrauch von GitFlow.

Können Sie sich vorstellen, was passiert, wenn Sie so ein komplexes Regelwerk einrichten? Das ist richtig - Menschen machen Fehler und brechen sie versehentlich. Im Fall von GitFlow geschieht dies ständig. Hier ist eine kurze, keineswegs vollständige Liste der häufigsten Fehler, die ich beobachtet habe. Diese werden ständig wiederholt, manchmal jeden Tag, oft immer wieder von denselben Entwicklern, 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 obige Artikel macht das gleiche Argument. Aber das ist eine separate Diskussion. Objektiv gesehen ist es jedoch ein ziemlich schwerer Standard mit viel manueller Verwaltung, und es erfordert viel kognitiven Aufwand.

Sie müssen einfacher beginnen. Machen Sie sich jetzt keine Sorgen über einen Verzweigungsstandard. Konzentriere dich zuerst auf gewöhne dich daran, git zu benutzen. Sie brauchen wirklich nur ein paar Operationen, um loszulegen:

  • klon
  • ziehen
  • ast
  • verschmelzen
  • verpflichten
  • Drücken
  • wissen darüber, wie .gitignore funktioniert
  • vielleicht tag

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

Steigern Sie schrittweise das Wissen

Von hier aus können Sie sie schrittweise über etwas fortgeschrittenere Anwendungen informieren.

  • Bringe ihnen den epischen Stash-Befehl bei
  • Bringen Sie ihnen bei, wie man Reset verwendet, wenn sie das gerade vorgenommene lokale Commit wegwerfen möchten
  • Bringen Sie ihnen bei, wie man Änderungen vornimmt
  • Bringen Sie ihnen das Rebase bei, um unnötige Zusammenführungs-Commits zu vermeiden
  • Bringen Sie ihnen bei, wie sie interaktiv neu aufbauen können, um ihre Commits zu organisieren, bevor sie pushen
  • Bringen Sie ihnen bei, wie sie aus jedem Hash, Tag oder Zweig auschecken können

Stellen Sie insbesondere sicher, dass Sie die Gelegenheit nutzen, um ihnen sauberere Möglichkeiten zu zeigen, wie sie ihren Code in das Repository aufnehmen können, aber lehren Sie dieses Zeug auch in Schulungsaktivitäten und was Sie haben. Ein oder zwei Guru zu haben, an die sich Menschen wenden können, wenn sie sich nicht sicher sind, was sie tun sollen, hilft auch sehr. 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 einen Verzweigungsstandard

Sobald Sie den größten Teil des Unternehmens haben, der überhaupt mit git vertraut ist, dann, können Sie sich die Verzweigungsstandards ansehen. Die Wahl eines im Voraus ist aus mehreren Gründen eine wirklich schlechte Idee:

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

Sie sollten keinen Git-Workflow vom Berg aus weitergeben. Ihr Team muss Input 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 Einzelentwickler, um so tiefes Wissen zu haben, aber Sie brauchen definitiv mehrere, die es wirklich verstehen. Und Sie brauchen die überwiegende Mehrheit, um zumindest kompetent in Git zu sein, damit sie genug wissen, um etwas auf den Schienen zu bleiben.

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

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

11
jpmc26

Kauf ihnen ein Buch

Ehrlich gesagt bin ich direkt in das Lager gefallen, das Sie beschreiben. Ich kam 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 jedem zuvor verwendeten Quellcodeverwaltungssystem unterschied. Jetzt bevorzuge ich Git gegenüber jeder anderen Wahl.

Leider kann ich mich nicht erinnern, welches Buch ich zu der Zeit gelesen hatte, aber stellen Sie sicher, dass jedes Buch, das Sie für sie erhalten (oder auf das Sie zeigen), sich 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 zur Vereinfachung ... kaufen Sie bei jedem, den Sie möchten: 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.

9
Reginald Blue

Ich spiele damit, git dort vorzustellen, wo ich bin (von TFS), damit Ihre Frage für mich aktuell ist, zumal ich auch einige Rückschläge hatte, als ich das Thema ansprach.

In Peopleware sind die zugrunde liegenden Thesen des gesamten Buches:

Die Hauptprobleme unserer Arbeit sind nicht so sehr technologisch as soziologisch in der Natur.

Ich spreche das an, weil unser Problem kein technisches ist. git, obwohl ein wenig stumpf, ist wahrscheinlich nicht jenseits der Fähigkeiten von Ihnen oder meinen älteren Entwicklern, es sei denn, sie sind extrem dumm *.

Betrachten wir es aus der Sicht Ihrer Entwickler als Menschen, nicht als technische Maschinen:

Sie fordern sie auf, die Verwendung eines Quellcodeverwaltungssystems zu beenden, das sie (wahrscheinlich) beherrschen, und eines, das sie nicht beherrschen. Es ist ein bisschen so, als würde man einen git Experten bitten, die Verwendung von git einzustellen und zu svn zu wechseln, nicht wahr? Ich denke, die Git-Expertin wäre verärgert und würde wahrscheinlich nicht viel Mühe in svn stecken, weil git gut funktioniert und es Teile davon gibt, 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 von svn und git ist ihre Chance, es fallen zu lassen ^.

Die Senioren sind jedoch vorsichtig mit den Opportunitätskosten - wenn sie git lernen, dann sind sie nicht:

  • Lernreaktion/Winkel/Schnell/Blockchain/Kotlin (eine andere Sache, die sie als sollten Lernen empfinden).
  • DIY machen/schnitzen/segeln/Poesie/Glockenspiel/was auch immer sie eigentlich tun wollen zu tun.
  • Zeit mit ihren Kindern/Verwandten/Freunden/bedeutenden anderen verbringen.
  • Lieferung dieser "großen neuen Sache" - es gibt eine Frist, ein Budget usw. Sie sind wahrscheinlich besorgt darüber.

    "Ich muss alle oben genannten Schritte ausführen. Warum muss ich git verwenden, wenn wir bereits über eine 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 völliges Umdenken darüber erfordert, wie Sie Entwickler sind? Haben Sie die Vorteile von git Funktionen erklärt?

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 zentralisierten Denkweise der Quellcodeverwaltung befinden - nicht nur technische, sondern auch kulturelle Veränderungen, und wir wissen, wie schwierig es ist, eine Kultur zu verändern.

Überlegen Sie sich also im Grunde, was Sie von Ihren Entwicklern verlangen, und stellen Sie sicher, dass dies aus den richtigen Gründen geschieht. Wenn du es nur machen willst, weil svn dumm und alt ist und niemand mehr benutzt, dann ist das in Ordnung, aber es ist schwieriger, es an andere zu verkaufen, die nicht so denken wie du und einfach nur mit ihren weitermachen wollen Tag. Sie müssen die Vorteile in Begriffen angeben, die für Ihr Team und das Projekt sinnvoll sind. Wenn Sie sie dazu bringen können, zuzustimmen, dass git den Schmerz wert ist, müssen Sie sich keine Sorgen machen, dass sie die Technologie lernen, sondern nur dem von Ihnen eingerichteten Workflow zustimmen.

Viel Glück.


* Ich kann den Leuten nur empfehlen, sich daran zu erinnern, dass die meisten Entwickler in technischen Fragen nicht dumm sind. Verwerfen Sie das einfach als Grund, bis es keine anderen Erklärungen mehr gibt.

^ und beschäftigungsfähiger sein, worüber Senioren vielleicht nicht so viel nachdenken, insbesondere angesichts des in unserer Branche vorherrschenden Alters.

4
conradj

Nach meiner Erfahrung können sich einige Leute mit Git wohlfühlen, ohne es zu verstehen. Sie finden ein grundlegendes Tutorial, lernen grundlegende Befehle kennen und können loslegen. Das ist wahrscheinlich, wo Sie Junior-Berater passen. Ich glaube nicht, dass man in ein paar Tagen wirklich Git lernen kann!

Andere Leute können das nicht, sie müssen verstehen, was Git macht, und das braucht mehr Zeit. Ich war in dieser Kategorie; Ich fand es sehr hilfreich, mit Inhalten des Verzeichnisses .git Zu spielen. Dann begannen die Dinge für mich zu klicken. Auch Einzelgespräche mit unserem technischen Leiter halfen.

Sie können eins zu eins Tutorials machen, weil die Leute unterschiedlich lernen und über verschiedene Teile wirklich verwirrt sein können. In einer eins zu eins Sitzung ist es einfacher zu sehen und zu lösen. Wenn sie wirklich gestört sind, dass sie nicht verstehen, wie git Zweige verfolgt, zeigen Sie ihnen den Inhalt des Verzeichnisses .git Und so weiter ...

4
Akavall

Ich denke, dies ist weniger eine Frage der Softwareentwicklung als vielmehr eine Frage der Psychologie. Ich möchte auf Algorithms to Live By: The Computer Science of Humand Decisions Verweisen. 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 gibt eine solide mathematische Theorie, warum dies der Fall ist, um etwas in einem bestimmten Intervall optimal zu nutzen.

Dies erstreckt sich auch auf Alter und Erfahrung. Menschen sehen ihr eigenes Leben als Intervall, und nach einer bestimmten Erkundungsphase ist es optimal, Ihr 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. Sie wählten normalerweise das Familienmitglied, während jüngere Leute eher die berühmte Person wählten. Auf die Frage, 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. Dies deutet darauf hin, dass Menschen aufhören, ihre sozialen Netzwerke aufzubauen, wenn sie glauben, dass sie weniger von der Erforschung als von der Nutzung dessen haben, was sie bereits wissen.

Ihre leitenden Ingenieure sind wahrscheinlich älter, sie haben wahrscheinlich einige Versionskontrollsysteme durchlaufen. SVN ist wahrscheinlich das beste, das sie bisher verwendet haben (zumindest bei den älteren Versionssystemen, 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 das Beste ist, das sie jetzt ausnutzen.

Dies ist die grundlegende menschliche Psychologie und Hunderttausende von Jahren evolutionärer Optimierung, gegen die Sie kämpfen.

Sie müssen ihnen zeigen, a) wie lange sie eine Karriere vor sich haben, um sie darauf vorzubereiten, aus einer anderen Perspektive über das Intervall nachzudenken, in dem sie sich selbst sehen, und b) fragen Sie sie was sie denke ist großartig und was sie in SVN vermissen. Sie können Hunderte von Vorteilen von git erläutern, aber sie haben bereits eine klare Vorstellung davon, warum SVN das Beste ist, nachdem sie wahrscheinlich zuvor 5 Versionskontrollsysteme erlebt haben. Sie müssen den Riss in der Rüstung dieses Arguments finden und dann sehen, ob git diese Probleme lösen kann, dann haben sie sich selbst überzeugt.

3
CodeMonkey

Geben Sie ihnen kein Tool oder eine GUI, um Git zu verwenden. Es wird nur die Dinge verwirren. Git wurde entwickelt, um auf einer Befehlszeile ausgeführt zu werden, sodass dies wahrscheinlich der Ort sein sollte, an dem es gelernt wird. Jede GUI kann ihre eigenen Begriffe und Besonderheiten haben. Halten Sie sich an das, was einfach ist.

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

  • Möglichkeit zum Festschreiben, wenn keine Verbindung zum Netzwerk besteht
  • Fähigkeit, eigene Zweige zu bauen und zu spielen
  • Patches, die untereinander gesendet werden können und dennoch den Track zusammenführen
  • kirschernte ohne Schmerzen.
  • änderungen neu begründen
  • finden von Fehlern mit Git-Spleiß

Ich bin mir sicher, dass SVN in den letzten Jahren weitergezogen ist, aber das waren Dinge, die eine Welt voller Schmerzen verursachten. Wenn die Entwickler erkennen, dass dieses neue Tool nicht nur eine ausgefallene Sache ist, sondern solide Vorteile für ihre Arbeit hat, werden sie möglicherweise eher dahinter stehen.

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

2
Jeremy French

Sag ihnen, sie sollen sich keine Sorgen machen

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

Zeigen Sie ihnen, wie git reflog funktioniert. 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 (auch von der Fernbedienung!).

Verwenden Sie keine GUI

Eine GUI wird ihnen einen schnelleren Start ermöglichen, aber sie werden Git nie wirklich verstehen. Außerdem habe ich festgestellt, dass es nicht "fast unmöglich zu verlieren" ist, wenn Sie eine Git-GUI verwenden. Ich habe gesehen, wie GUIs schreckliche Dinge getan haben, z. B. beim Zusammenführen eine Checkliste vorzulegen. Wenn der Benutzer ein Element deaktiviert, löscht er diese Datei ohne Warnung und ohne Aufzeichnung aus dem Verlauf. Eine GUI ist weitaus schlimmer als nur das Erlernen von Befehlszeilen-Git.

Pair-Programm-Code wird festgeschrieben

Lernen git add -A gefolgt von git commit sollte nicht zu schwer sein, aber insbesondere 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 oben 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 sich früh und häufig verpflichten und dass sie nicht mit einer GUI den falschen Weg einschlagen, und sie werden bald feststellen, dass sie Git ihren Code noch mehr als andere Quellcodeverwaltungen anvertrauen können Systeme in der Vergangenheit.

2
Kyralessa

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, Zweige behalten ihre eigenen Arbeitskopien von Dateien, die einfacheren Verwendungen von git rebase Werden mit gl Fuse Behandelt. usw.), während Sie ein zugrunde liegendes Git-Repository für die Zusammenarbeit verwalten oder wenn Sie etwas Ungewöhnliches tun müssen. Außerdem sind die Nachrichten etwas unerfahrener. Und die Befehle sind nah genug, um als Sprungbrett zu fungieren, wenn sie ein System verwenden müssen, ohne aus irgendeinem Grund gitless darauf zu sein.

1
David Heyman

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 "Nur die relevanten Ordner komprimieren" bevorzugten. Es war besorgniserregend, wenn ein undurchsichtiges Tool den Inhalt meines Arbeitsverzeichnisses änderte und 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 verwaltet die Interaktionen zwischen dem Remote-Repository "Origin" und dem, was Git für mein lokales Arbeitsverzeichnis hält.

  • Ich behalte auch ein "echtes" lokales Arbeitsverzeichnis, das von dem, was Git für mein lokales Arbeitsverzeichnis hält, getrennt ist. Ich synchronisiere diese beiden Arbeitsverzeichnisse manuell, wodurch ich viel komfortabler bin, dass alle Änderungen in meinem Arbeitsverzeichnis das sind, was ich beabsichtigt habe.

0
Jasper

Kann ich diesen Mitarbeitern helfen, Git zu lernen?

Bist du sicher, dass das Problem Git ist und nicht etwas anderes? Was ich aus dem Kommentar erhalte, ist, dass das Management beschlossen hat, etwas zu ändern, ohne sich von den leitenden Mitarbeitern einkaufen zu lassen, und jemanden beauftragt, der jünger ist, die Änderung voranzutreiben. Das scheint ein guter Ausgangspunkt für ein Scheitern zu sein, was auch immer die Änderung ist. Git-Komplexität ist kein Problem, das Problem ist, dass ihnen eine Änderung aufgezwungen wird, die sie nicht für nötig halten.

Konzentrieren Sie sich also nicht darauf, wie Sie ihnen Git beibringen können, solange sie keinen Vorteil für den Schalter sehen, den sie mit den Füßen ziehen werden. Zeigen Sie ihnen, wie Git eine Lösung für Probleme ist, die sie jetzt haben. Nicht wie Git ihnen Dinge bieten kann, die sie noch nicht brauchen, nicht wie Git eine Lösung für Probleme anderer Leute bietet, wie Git Probleme löst, gegen die sie gerade kämpfen. Dann wird es kein Problem sein, ihnen Git beizubringen.

0
AProgrammer

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

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

  • Erstellte Niederlassungen, da das Management nicht bereit ist, sich zwischen widersprüchlichen Anforderungen zu entscheiden
  • Haben für jeden Kunden eine Zweigstelle anstelle von Konfigurationsschaltern verwendet.
  • Es musste für jeden Kunden eine Fehlerbehebungsniederlassung vorhanden sein, da das Management nicht bereit war, alle Kunden auf die gleiche Version der Software zu aktualisieren
  • Usw.

Sobald mir einige sagen, dass ein Werkzeug gut in der Verzweigung ist, sagt mir mein Verstand.

Das Management möchte nicht entscheiden, in welche Richtung sich das Unternehmen entwickelt, und möchte lieber, dass ich mein Leben damit verschwendet habe, meine Arbeit in 101 verschiedenen Branchen zusammenzuführen und 101 verschiedene Versionen der Software zu testen.

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

Jedes Mal, wenn ich mir den Verlauf in Git anschaue, ist es sehr schwer zu erkennen, warum Code geändert wurde, da 50% oder mehr des Verlaufs Zusammenführungen sind, die logischerweise niemals öffentlich sein sollten, und sie 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 Vertrauensserver getestet wurde.
  • Es gibt eine einfache Möglichkeit, Codeüberprüfungen zu verfolgen
  • Wo immer ich ein "get" mache, wird der Code immer kompiliert und funktioniert
  • Wo ich meine Änderungen pushen kann, ohne ein Rennen mit jemand anderem haben zu müssen oder im Büro herumlaufen zu müssen, um zu sehen, ob ich den Build gebrochen habe.

Lösen Sie also die wirklichen Probleme und wenn Git Teil der Lösungen ist, die Ihre erfahrenen Entwickler kaufen werden, erwarten Sie jedoch nicht, dass sie Git mögen, nur weil es ein cooles Spielzeug ist, das „magische Zusammenführungen“ durchführen kann.

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

Ich gehe davon aus, dass Kiln ( http://www.fogcreek.com/fogbugz/devhub ) oder sogar GitHub, der einen "Pull Request" -Workflow verwendet, erfahrene Entwickler glücklich machen würde , z.B Beginnen Sie nicht mit dem niedrigen Level, sondern mit dem verbesserten Prozess.

0
Ian