Veröffentlicht am 13-03-2019

Zusammenarbeit mit Git

Weil jeder gute Artikel mindestens ein Gif benötigt

Es gibt keine direkte Linie, um Programmierer zu werden, aber irgendwann muss sich jeder mit Git und der Versionskontrolle auseinandersetzen. Wenn Sie ein Codierungs-Bootcamp durchlaufen, so wie ich es gerade bin, registriert sich Git wahrscheinlich nicht als sehr relevant für Sie inmitten des Meeres unbekannter Terminologie und fehlender geschlossener Klammern.

Ich weiß, irgendwann dachte ich immer wieder beim Tippen

git add.
git commit -m "ein weiteres Commit"
git Push Ursprungsmaster

Es schien wie ein weiteres unerklärliches Programmierritual, das Sie in diesem Bereich finden, wie "foo" als "bar" oder "Hello World" in eine Datei zu setzen, die kein anderer Mensch je sehen wird. Instructoren / Tutorials / andere Programmierer sagen Ihnen vielleicht, dass es wichtig ist, sich früh und oft an das Git-Commiting zu gewöhnen, aber da Projekte für Anfänger so klein sind und der Code, den Sie schreiben, eh kaum funktioniert, ist es nicht Es scheint ein beliebiger Punkt zu sein, um die heiligen Git-Wörter nach jeder neuen aufgeblähten Funktion zu wiederholen, die Sie schreiben.

Git wird das Leben wirklich nicht einfacher machen, bis Sie mit anderen Programmierern Code schreiben. Obwohl ich mich lieber als Autodidakt empfinde, habe ich mich dazu entschieden, die Programmierung durch ein persönliches Coding-Bootcamp zu erlernen, um zu lernen, wie man an komplizierten Projekten mit großen Gruppen von Menschen arbeitet. Ich hatte das Glück, bei meinem ersten gepaarten Programmierprojekt in einem Dreierpaar zu sein, und ich habe viele wertvolle Erfahrungen mit der Versionskontrolle gesammelt, von der ich entdeckte, dass sie für Codierungen außerhalb von kollaborativen Aufgaben verwendet werden sollte.

Sie müssen jedoch nicht mit Code arbeiten, um zu verstehen, warum Git ein so nützliches Werkzeug ist.

Warum überhaupt Git benutzen?

Bei meinem vorherigen Job als Programmassistent in einer Organisation mit weniger als einem Dutzend Menschen gab es eine stark ermutigte Ethik der Zusammenarbeit [dh schlechte Führung]. Dies bedeutete, dass wir alle oft ermutigt wurden, als Gruppe mit nachverfolgten Änderungen zu schreiben, zu bearbeiten und zu Word-Dokumenten beizutragen.

Stellen Sie sich vor, Sie schreiben den ersten Entwurf eines wichtigen Briefs und senden ihn dann an einen Ihrer Manager, der ihn an Ihren Chef weiterleitet, der ihn auf einem iPad bearbeitet und an zwei andere Personen in Ihrem Büro gleichzeitig weiterleitet. Einige Zeit später bemerken Sie einige Abweichungen in den Dateinamen, die Sie mit den E-Mails verbunden haben, in denen Sie sich gerade befanden. Sie wissen, dass es mindestens zwei verschiedene Versionen des Dokuments gibt, von denen nur eine zur weiteren Bearbeitung an Ihren Vorgesetzten zurückgekehrt ist. Dieser großartige Schlussabschnitt, den Sie geschrieben haben, ist verschwunden, abgesehen von einer abhängigen Klausel, die unbeholfen zwischen zwei Sätzen eingefügt ist, die Sie zweimal gelesen haben und immer noch nicht verstehen.

Dankenswerterweise wurden Änderungen nachverfolgt, so dass Sie etwas haben, das einem Datensatz nahekommt, der den Pfad von Ihrer ursprünglichen Prosa bis zu dem aufgeblähten Schwall beschreibt, aus dem der Brief geworden war. Sie haben jedoch nur die Möglichkeit, das Dokument in seiner aktuellen Form oder mit allen Ihren Kollegen anzuzeigen 'Beiträge kombiniert zu einem durcheinandergebrachten Haufen von rotem und schwarzem Text.

Sie beschließen, sich in den Kampf zu stürzen und das Dokument auf der Grundlage der aktuellen Version zu bearbeiten. Jeder, der versucht, das Büro wieder auf Kurs zu bringen. Ihre Chefs mögen diese Initiative, weil sie nicht wissen, dass der Begriff "Verwalten" meistens abwertend verwendet wird.

Kurz darauf wurde eine Besprechung des Personals einberufen, um dieses Chaos auszuräumen. Ihre Bearbeitung enthielt keine sehr wichtige Statistik, die in einer früheren Version irgendwie gelöscht wurde. Sie muss auf jeden Fall geändert werden. Dieser sehr wichtige Brief muss an diesem Nachmittag ausgehen, so dass Sie keine Zeit mehr haben, herumzuspielen. Ein Manager hat die Aufgabe, einen Absatz über etwas Sinnvolles hinzuzufügen und ihn dann an den Büroleiter weiterzuleiten.

Sie glauben, dass alles gelöst ist, aber jetzt gibt es einen stressigen E-Mail-Austausch, bei dem das Dokument tatsächlich die neueste Version darstellt, da das Dokument zu diesem Zeitpunkt auch in mehreren Versionen in verschiedenen Posteingängen, lokalen Computern und natürlich dem gemeinsam genutzten Laufwerk (und noch immer) vorhanden ist einige Verwirrung darüber, in welchem ​​Ordner es sich befinden sollte).

Sie legen den Kopf hin und tun so, als würden Sie den Rest des Tages arbeiten, während Sie die anderen Köche in der Küche damit beschäftigen. Sie fangen an zu denken, es sei Zeit für eine Karriereänderung.

Stellen Sie sich nun vor, dass dieser Brief kein Word-Dokument ist, sondern eine Anwendung, die aus Hunderten von Dateien besteht und Codezeilen von Kilometern enthält, in denen ein einzelnes Komma unpassierbar die gesamte App unbrauchbar machen könnte - in der Produktion könnte es eine ganze Firma sein ein Halt Eine Codebasis ist viel umfangreicher und erwartet eine lange Lebensdauer. Daher ist es nicht nur wahrscheinlich, dass mehrere Entwickler mit unterschiedlichen Skillsets daran arbeiten, sondern praktisch unvermeidlich.

Es ist nicht schwer zu erkennen, wie leicht der Entwicklungsprozess mit so vielen beteiligten Köpfen schief laufen kann.

Trotz der vieldeutigen Terminologie (Fork vs. Branch vs. Clone) führt Git mehrere grundlegende, aber unglaublich nützliche Funktionen aus:

  1. Sie können an jedem Punkt der Entwicklung verschiedene Versionen Ihres Codes protokollieren und wiederherstellen.
  2. Mit github können Sie Ihre Daten auch remote sichern.
  3. Sie können Ihren Code für andere Entwickler freigeben und umgekehrt, und alle von Ihren Mitarbeitern vorgenommenen Änderungen verfolgen und überprüfen.

Die Arbeit an einem Projekt von kleinem Umfang brachte mir mehrere Lektionen für die Verwaltung einer Codebasis während ihrer Entwicklung bei. Ich kann nicht behaupten, ein Experte für die Verwendung von Git zu sein, aber ich werde hoffentlich in der Lage sein, eine detailliertere Erläuterung des Git-Arbeitsflusses zu schreiben, wenn ich mehr Erfahrung habe. Hier sind meine wichtigsten Ratschläge für die Verwendung von Git mit anderen.

1. Der Meisterzweig ist heilig und sollte als solcher behandelt werden

Ihr Master-Zweig sollte immer eine funktionierende Version Ihres Programms enthalten - die Version, die Sie jemandem zu einem bestimmten Zeitpunkt anzeigen können, ohne sich entschuldigen und erklären zu müssen, dass „es gestern ganz gut funktioniert hat“. Möchten Sie eine neue Funktion hinzufügen? Fügen Sie einen Zweig hinzu - bringen Sie ihn zur Arbeit - zusammenführen - löschen Sie den Zweig - klopfen Sie sich auf den Rücken, wechseln Sie zu einem neuen Zweig.

Sie möchten nicht die perfekt funktionierende App einer anderen Person in die Luft jagen, tun Sie es also auch nicht für sich.

2. Nur Commit was funktioniert

Vergewissern Sie sich, dass Sie keinen Code für die laufende Arbeit speichern, da Sie UNBEDINGT unterbrochen werden und UNBEDINGT UNBEDINGT in Ihren Hauptzweig einbinden, wenn Sie Regel 1 verletzen. Während git add. Normalerweise eine hilfreiche Verknüpfung ist, sollten Sie einen Teil des Codes, den Sie mit einer Gruppe bearbeiten, aber nicht vollständig implementiert sind, aus irgendeinem Grund verschieben. Stellen Sie jedoch sicher, dass Sie sie mit git reset - the_file_you_want_to_unstage deaktivieren

Wenn Sie sich bewusst machen, welche Änderungen Sie mit git add nachverfolgen, werden Sie auch zu einem fokussierten und effektiveren Programmierer.

3. Machen Sie Ihre Commit-Nachrichten so kurz, aber so detailliert wie möglich.

git commit -m “Committing ist eine große Redundanz. Schreiben Sie ein paar weitere Informationen, nicht nur aus Gründen der Höflichkeit, nicht nur Ihren Kollegen, sondern auch der zukünftigen Version von Ihnen (ehrlich gesagt haben Sie keine Ahnung, was Sie bisher durchgemacht haben). „Refactoring“ „Fehler behoben“ „Oops“ „Neues hinzugefügt“ hilft niemandem, wenn er versucht herauszufinden, wer den Code gebrochen hat (wir alle wissen, dass Sie es waren) oder wo Sie nach Fehlern suchen müssen .

Unabhängig davon, für welche Organisation Sie am Ende arbeiten, haben Sie Konventionen, an die Sie sich halten können, aber gewöhnen Sie sich früh daran, Ihre eigenen Konventionen zu befolgen. Ich habe immer versucht, den Namen der Datei / Klasse / Methode oder das, was ich seit meinem letzten Commit geändert habe, anzugeben. Beispiel:

git commit -m "Refactored SomeClass # some_method"

Auf diese Weise kann jeder, der den Verlauf der Änderungen an some_class.rb überprüft, die Änderungen im Commit schnell nachvollziehen, ohne die Codeänderungen manuell überprüfen zu müssen.

Diese Empfehlungen machen die Zusammenarbeit mit anderen bei git zu einem viel reibungsloseren Erlebnis, und wenn Sie sie bei der Arbeit an Soloprojekten einsetzen, werden Sie auch besser organisiert und weniger frustriert sein.

Und ist es nicht ein Ziel, auf das Sie hinarbeiten sollten?

Siehe auch

Big Tech übernimmt die Kontrolle von Ihnen.Wie die Wireless Charging-Technologie das Spiel für Unternehmen verändert